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.
Related
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.
Is there a way to convert timezones like "America/Los_Angeles" to timezone shortname "PDT" in ruby?
The abbreviations are typically contextual - so "PDT" only applies while daylight saving time is in operation.
Judging by the documentation, if you format a Time with strftime and use a format string of %Z, you should get the time zone abbreviation.
Personally I dislike using the abbreviations, given that they're ambiguous and can cause a lot of confusion. (I've seen people using "PST" year-round, for example, referring to "7/20/2012 9:00 PST" for example - a date/time which makes no sense.) That's a different matter though :)
More explicit answer:
Time.now.in_time_zone("America/Los_Angeles").strftime('%Z')
I have a page that tells the user to input a time in the format hh:mm:ss. This is obviously fine for English speaking audiences, but is this an acceptable international notation?
If not, could you give me some examples of how other countries display this kind of information to the user.
In terms of time, it is usually either in format hh:mm:ss or h:mm:ss, that is you either do zero-padding or no zero padding for single digits hours.
Another thing is, the format - distinction between 12 hours and 24 hours, that also varies from Locale to Locale.
Lastly, you should take into account local user's time zone - it is natural to enter the time in relation to current time zone.
How would you go about these options? Basically, it depends on what your UI look like. If you have just one text box where user can enter free-form text, you should actually parse the text according to valid Locale format. In that case you can give an example of the format, by formatting current day, so the label would say something like "Enter the time (for example: 16:36:11):".
Other approach is to have two (hour/minute) or more text fields (seconds) separated by time separator (":") and possibly conditional AM/PM radio button group (or drop down). In that case it would be a bit harder, because to do that correctly, you should actually analyze the localized pattern (on what is and what is not supported) and dynamically create UI elements (I don't want to see AM/PM stuff as I am using 24 hours time naturally) as well as validation rules...
I know dates are different between different country, but time is pretty standard. you won't have problem with French, spanish, german, UK... i don't know for asian country tho...
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. :-)