My comments on draft-newman-datetime-00.txt
Markus G. Kuhn
kuhn at cs.purdue.edu
Sun Dec 29 01:03:45 UTC 1996
I am the author of the ISO 8601 summary on
and I just found your new Internet draft
about a standard date and time notation for the Internet.
I agree that such a standard would be very useful and hope to be able to
assist you in finishing it.
Here are some comments that I wrote down while reading your first draft:
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
You'll find there also other related standards regarding UTC and time
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.
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.
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.
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.
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!).
7) You could add a reference to the technical corrigendum 1 for ISO 8601,
which fixes a few typos in the standard.
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.
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.
These are my suggestions for your draft. Please let me know when you have
made any changes or have any questions. Thanks for your effort!
Markus G. Kuhn, Computer Science grad student, Purdue
University, Indiana, USA -- email: kuhn at cs.purdue.edu
More information about the tz