I am trying to use Mailchimp.com's API 3.0 to add people from a PHP web server, but my datetime values for "timestamp_signup"and "timestamp_opt" are being rejected on insert subscriber.
According to this page :
https://developer.mailchimp.com/documentation/mailchimp/reference/lists/members/
the format of timestamp_signup and timestamp_opt is ISO 8601 format and both are writeable.
But all the versions I have tried have been rejected:
"2018-10-19T13:50:37+01:00"
"2018-10-19T13:50:37"
"2018-10-19T13:50"
"2018-10-19"
Many thanks
Ian
What is the correct format?
Great find Ian, that seems to be a new issue within the MailChimp API that occurred first with us around a week ago, but it seems to also not happen always.
I contacted the MailChimp Support and they confirmed it seems to be a problem on their end and that they will look into it.
For now I can confirm that your workaround (YYYY-MM-DD HH:MM:SS) works fine but it is not what the MailChimp API states and should definitely be fixed by them.
The format to use is YYYY-MM-DD HH:MM:SS
Not ISO 8601 which is YYYY-MM-DDTHH:MM:SS+HH:MM
Mailchimp.com's software generated correct ISO8601 dates when it sends datetimes back. However it requires the "T" to be a space, and will reject a date that includes the timezone (the +HH:MM on the end).
This is contrary to my reading of the standard.
#Ian is correct. The right format is not ISO 8601 but the classic one:
YYYY-MM-DD HH:MM:ss
Be careful if you're using JS/NodeJS with momentJS for instance. The right format is the following:
moment().format("YYYY-MM-DD HH:MM:ss")
The seconds are in lower case. Otherwise, you will have the fractional value which results in an error on the Mailchimp side.
Related
If a date is specified in the format
start=2021-04-05&end=2021-05-05
does that mean that 2021-05-05 is excluded from the results?
and it's returning up to 11:59:59 on the 4th?
In an API I'm using, it seems to be behaving the same as
start=2021-04-05T00:00:00Z&end=2021-05-05T00:00:00Z when no time is specified.
A few things:
I think you are asking about the full-date format from RFC 3339, which is the same as the ISO 8601 extended date format: YYYY-MM-DD
Neither specification says anything about inclusivity or exclusivity of date-only ranges.
ISO 8601 does talk a bit about ranges (they call them intervals), but they are defined as a pair of instants, not whole dates.
The typical best practice (in my experience) would be to use a fully inclusive range for date-only values, or a half-open range for date-time values. For example:
[2021-04-05, 2021-05-05]
[2021-04-05T00:00:00, 2021-04-06T00:00:00)
However, this is not a hard rule. The actual details would be highly specific to the particular API you are using and how the authors of that API designed it to function.
A whole date like 2021-04-05 is not necessarily the same thing as 2021-04-05T00:00:00. In many cases, the reason to use a whole date is to not associate a time or a time zone at all. But again, this is highly implementation specific.
Nothing you've shown would imply that UTC (Z) is being used. If that's how the API is behaving, that's another implementation detail of that API.
I have unix timestamp in table, wants to show to user using Carbon. How can I achieve ?
e.g.
1487663764.99256 To
2017-02-24 23:23:14.654621
Did you check the carbon docs? I think this is what youre looking for:
Carbon::createFromTimestamp(-1)->toDateTimeString();
Checkout http://carbon.nesbot.com/docs/#api-instantiation
There are several ways to create Carbon instances described in the Carbon documentation, which is linked at the bottom of the project's README. The relevant section is this:
The final two create functions are for working with unix timestamps. The first will create a Carbon instance equal to the given timestamp and will set the timezone as well or default it to the current timezone. The second, createFromTimestampUTC(), is different in that the timezone will remain UTC (GMT). The second acts the same as Carbon::createFromFormat('#'.$timestamp) but I have just made it a little more explicit. Negative timestamps are also allowed.
So you can just do:
$carbon = Carbon::createFromTimestamp($dbResult['SomeTimestampColumn']);
If you really love your fluid method calls and get frustrated by the extra line or ugly pair of brackets necessary when using the constructor you'll enjoy the parse method:
Carbon::parse(1487663764);
Carbon::parse('first day of next month');
An API returned time in this format:
"05/29:00:45"?
It was probably manually entered.
I understand how to parse it but is this a common time format in some countries or software?
the format is month/Day and time (hours/second). Probably the correct format it will be 05/29/00:45
I am saving all my notes in a log file. Each line is a note, suffixed by tags, and prefixed by a date and time marker, which currently looks like this: [12.20.09:22.22] ([date:time].
I am planning to have this a long-living format. Notes will be logged willy-nilly with this format 20-30 times a day for years to come. I foresee numerous kinds of parsing for analytics, filtering, searching ...
I am worried about the [ ]s though. Could they possibly trip some parsing code (someone else's if not mine)? What would be the most non-confrontational marker?
If you end up going with your own format, can I recommend ISO 8601 for your date and time format.
In summary, the basic format is:
yyyy-mm-dd hh:mm:ss
You can extend this with timezone and microsecond info if you wish. Timezone is recommended or assume UTC.
With the date/time in this format there's no confusion over which is the month and the day. And it has the bonus of sorting using a basic string sort.
I'd consider using either XML or JSON as the format for the file.
In particular your date/time marker is ambiguous. Is it mm/dd/yy or dd/mm/yy? Or even yy/mm/dd? And in what timezone is the date and time?
Both XML and JSON define a way to have dates that are culture and timezone independent, and (best of all) there's masses of tooling available for both formats.
XML datetime format is defined here: for example, 2000-01-12T12:13:14Z.
JSON datetime format is defined as the number of seconds since Jan 1, 1970, so it's a bit uglier: { currentDate: "#1163531522089#" }
If you want everything to last in a long-lived format, then the metadata needs to be as explicit as possible. If it's intended to be long-lived, then many others will need to read it, as easily as possible.
I agree with Jeremy McGee: XML is an excellent choice. Even if no other data lives, then having it be in the format:
<note>
<datetime>
<year>
2009
</year>
<month>
12
</month>
. . .
</datetime>
<message>
Foo bar baz quox
</message>
<note>
cannot be misunderstood.
This depends on your data. However, if you escape them with a special character of some sort, (i.e. \]) and code accordingly to look at the previous character when finding a "[" or "]", you should have no problem.
Also, if you're open to a new format, I'm a fan of JSON as it's light weight and very useful.
Using '[]' as the markers would be ok provided that you allow the DSL the ability to escape the characters. This is typical of operations on text which need parsing.
As an example check out the typical regular expression syntax which enables '/' as the seperator, whilst letting the user specify an escape character such as '\'. You may get some more ideas from the likes of such Unix tools as; awk, sed and grep
I would tend to think a standardized format is the way to go, with JSON being my personal choice because of it's simplicity. Not only does that help to avoid parsing issues since others have already though about it, you are also given a lot more tools to work with over the life of the project.
For my application, I'm importing the calendar event from google calendar. The only problem which I'm facing is Time zone list. I'm getting the timezone as output from google calendar xml, which I have to check with time zone list and add time accordingly... so from where I can get this standard time zone list.. or some other alternative to achieve the same.
If you're using Java, use Joda Time - the time zone ID given by Google Calendar will be one the Joda Time understands. The standard TimeZone class may well understand it too, but I think Joda is more likely to.
Assuming you're seeing all the VTIMEZONE stuff that goes along with the event, you can ignore the details - just use the ID.
Unfortunately there are some time zone IDs which have changed over time - I can't remember any examples off-hand, but you may need to do some translations if you're provided with the "old" names.
If you're using .NET, you really need to be using .NET 3.5 and the TimeZoneInfo class. Unfortunately that uses Windows names instead of Olson IDs, but there's a translation list available somewhere (I can dig it out if you want).
If you're not using either of these platforms, you basically need to find a library which supports Olson Zoneinfo names. (That wikipedia article has some helpful links at the bottom.)
I would definitely try to find a library which will be able to give you the relevant information based on an ID, rather than using the rules given back in the calendar entry. Time zones change over time, and the zoneinfo database contains historical and future information, but that can't be easily encoded in the calendar entry.
There are some good articles about working with Erlang date/time libraries here:
http://www.trapexit.org/Category:DateTimeRecipes
Hope it helps.
Check out these function
calendar:datetime_to_gregorian_seconds({Date, Time})
calendar:gregorian_seconds_to_datetime(Seconds) -> {Date, Time}
Converting to "gregorian seconds" and correcting the timezone-offset and converting back to date form is half the solution.
There is no library to access timezone datafiles in Erlang/OTP, and as far as I know there is no third part library to get at it either. So your options are to yourself convert the available timezone databases to something usable from Erlang, or to settle for just knowing a few of them.
You know, unless you want to start a project to read timezone data in Erlang. :-)