On Sat, 28 Dec 1996, Markus G. Kuhn wrote:
I agree that such a standard would be very useful and hope to be able to assist you in finishing it.
I'd very much appreciate assistance. I'm no expert on time and only started this because ISO 8601 is so imprecise and complex that I wanted to create a precise, simple and free alternative reference for future Internet protocols.
1) You wonder, what standard defines UTC and leap seconds. This standard is ITU-R Recommendation TF.460-4. Using your credit card, you can now order very easily an electronic copy from the International Telecommunication Union Web server
Thanks for the info.
2) You suggest in section 3 to implement a rule that assumes for the 2-digit years 50-99 that they belong to the 20th century. Considering that Unix systems cannot represent in time_t any point in time before 1970-01-01 00:00:00Z, and that there are not any electronic documents on the Internet with a timestamp predating 1970, I suggest that 70 is a more reasonable border date. Gives us 20 more years and I expect to be almost dead or at least retired by then.
On the other hand, the Macintosh goes back to 1900 in timestamps, and there are probably more Macintoshes out there than Unix boxes. I'm trying to avoid a unix-centric (or US-centric :-) solution. It would certainly be useful to have documents published prior to 1970 on the web.
3) In section 4, you recommend the offset -00:00 to indicate UTC. One might consider the much shorter "Z" notation specified by ISO 8601 for this very common case. Saves a few bytes and is consistent with international radio practice (Z = Zulu = UTC). In section 5.4, you do already allow "Z", so here the text is inconsistent.
You misunderstood the text. "Z" refers to a time in the UTC timezone. "-00:00" refers to a time where the local time isn't UTC, but the offset is unknown, so UTC was used instead. This idea was discussed on the DRUMs mailing list in some detail. I'll try to clarify that section of the text.
4) In section 5.4, you allow the hour value 24. Both 00:00:00 and 24:00:00 are allowed by ISO 8601, but the notation 24:00 identifying the midnight at the end of the day is useful only for time interval notations (e.g., 20:00--24:00) and should not be used for unique timestamps. Better restrict the hour range to 00--23. Times like 24:00:01 definitely violate ISO 8601, but are supported by your grammar.
Actually, I think ISO 8601 is quite unclear about whether or not 24:00:01 is permitted. Nor does it say that it's useful only for interval notations. On the other hand, I'm inclined to take your advice since this particular point has confused a number of people.
5) You use the ugly "T" separator between date and time. ISO 8601 supports also the notion of separate date and time fields, so I suggest you simply define your format to consist of a date and a time field separated by a space. This is the ISO 8601 notation used by GNU RCS for instance (see option -zLT). I personally feel that separating date and time field by a space increases human readability and is preferable over the ISO 8601 combined dateTtime field format.
While ISO 8601 does say the "T" may be omitted, it certainly does not permit replacing it with space. I'm quite opposed to creating a new time format. There are already two standards (RFC 822 as amended by RFC 1123, and ISO 8601) so creating a third would be a great disservice to interoperability.
6) In section 6, you suggest an IANA registry of time zone names. Forget this. ;-) Time zone rules and names are thanks to the creativity of our politicians MUCH to dynamic and unstable. For very good reasons, ISO 8601 does not use time zone abbreviations at all. An excellent Internet list of current and historic timezone names that is constantly updated is already available in form of the tz database. You definitely should have a look at this first. <URL:ftp://elsie.nci.nih.gov/pub/tz*>. In addition, your proposal does not use any time zone names (which is a good thing!).
The registry becomes necessary, IMHO, thanks to the problems of recurring events in a calendar. Recurring events are usually defined in terms of "local time" which changes based on daylight rules. While it is possible to include the daylight savings offset rules with the calendar entry, having a registered name for those rules would be helpful. There has been a long discussion of this topic on the Internet calendaring mailing list. I was planning on using the database you mention as the "initializer" for the IANA registry of names.
7) You could add a reference to the technical corrigendum 1 for ISO 8601, which fixes a few typos in the standard.
I'm a bit uncomfortable referencing a corrigendum that I haven't seen or read. I'll try to obtain a copy.
8) You could make the minute part of the time zone optional and require that time zones with an integral number of hours offset to UTC (which are almost all!) should only be represented by a 2-digit offset. That is what GNU RCS does already and I think having only a single colon increases human readability.
I'm trying to minimize the optional portions, as that improves interoperability.
9) Feel free to copy my arguments against the ancient 12h am/pm time format from <URL:http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html>, in order to help eradicate this silly notation from new software (for instance, sendmail still uses am/pm in Received: header lines, which I consider to be very bad Internet time practice). You should also not use the am/pm notation in section 5.5, as the am/pm notation is really a very US-specific idea. The rest of the world has used the 24h notation for many decades and other languages than English do not even have terms like am/pm.
Agreed. Thanks.
I highly recommend you to join the tz@elsie.nci.nih.gov mailing list, where you'll meet a number of very experienced Internet date, time, and especially timezone experts. Send e-mail to tz-request@elsie.nci.nih.gov to join the club and check ftp://elsie.nci.nih.gov/pub/tzarchive.gz for previous discussion.
Will do. Thanks.