My comments on draft-newman-datetime-00.txt
Chris.Newman at innosoft.com
Thu Jan 9 20:17:48 UTC 1997
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
> 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
> 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
> 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
> 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
> I highly recommend you to join the tz at 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 at elsie.nci.nih.gov to join the club
> and check ftp://elsie.nci.nih.gov/pub/tzarchive.gz for previous discussion.
Will do. Thanks.
More information about the tz