Hello! I am the author of the ISO 8601 summary on http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html and I just found your new Internet draft ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt 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 http://www.itu.int/itudoc/itu-r/rec/tf.html You'll find there also other related standards regarding UTC and time signal transmission. 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 am/pm. 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. 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 -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu