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
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.
On Sat, 28 Dec 1996, Markus G. Kuhn wrote:
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've got a better argument for why this is a bad idea. Many people implement by example and only look at the standard when things break. If we make the minutes optional for the offset, these people will probably never see minutes and their implementations will break in those countries which use minute offsets. So in the interest of interoperability, we shouldn't make the minute part of the offset optional.
In message <Pine.SOL.3.95.970115174526.15280R-100000@eleanor.innosoft.com>, Chr is Newman wrote:
On Sat, 28 Dec 1996, Markus G. Kuhn wrote:
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've got a better argument for why this is a bad idea. Many people implement by example and only look at the standard when things break.
You argue that it is good standards writing practice to let unprofessional implementors get away with not reading the spec? If someone does not look at the standard, then he or she deserves not to be called a good software engineer. You can't make any protocol standard fully guessable by example. In contrast to ISO documents, RFCs are VERY widely read and VERY easily available for anyone who is even just slightly interested. You should expect the users of your standard to read the standard.
If we make the minutes optional for the offset, these people will probably never see minutes and their implementations will break in those countries which use minute offsets.
So they get punished with bug reports and they don't deserve it better! They probably will also not understand the -00:00 or Z and will forget to accept the fractional seconds. That's no way to develop any quality software system. I do not have very strong feelings about the optionality of the minute offset, but my arguments for it are: - only *very* few countries use it today and time zones are so often redefined that there is some good hope that the 30-min offset zones will disappear in 2020 or so. Then, we would not carry around any more the obsolete minute fields in our headers. - I personally think that the hour only offset is much more readable and that the additional implementation effort (one single "if" in my sample code) is so trivial that it is really not worth any discussion. Two points, where I have much stronger feelings about: The "T": - It simply looks ugly - ISO 8601 defines both a syntax for a date field and for a time field, and protocol designers do not violate the standard if they transmit a date and a time field separated by a space character, the normal field separator in many systems. The T was provided where for some reason (sortability, atomicity, etc.) you want to keep the date and time in one single field on database systems that separate fields with spaces. I hope that we can get an explanation for the "T" along these lines into the next revision of ISO 8601. The decimal comma: - The decimal dot is clearly THE decimal separator dominating in computer text representations of numbers. All ISO programming languages use the decimal dot exclusively and in ISO 6093:1985 "Information processing -- Representation of numerical values in character strings for information interchange", the decimal dot is the default decimal separator. I hope that we can convince the ISO 8601 authors to drop the preference for the decimal comma after reviewing other standards like ISO 6093 in the next revision. In addition, notations like 1970-01-01 00:00:00Z have become pretty common usage on the tz mailing list and in a number of USENET newsgroups that I read regularly. However, I have almost never seen the "T" anywhere used and my experience is that people who see the ISO 8601 standard the first time do not like it a lot. Another suggestion: It would be great if we could get the format that Paul Eggert and I suggested being mentioned as a named profile in the next revision of ISO 8601. Then the RFC would only have tutorial function (repeat the definition of the profile and provide some examples, example code, and usage guidelines). I'd say, it is time that we get involved in the work on the next revision of ISO 8601. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu
On Thu, 16 Jan 1997, Markus G. Kuhn wrote:
You argue that it is good standards writing practice to let unprofessional implementors get away with not reading the spec? If someone does not look at the standard, then he or she deserves not to be called a good software engineer. You can't make any protocol standard fully guessable by example.
It's good standards writing practice to do everything possible to help implementors, however unprofessional or stupid, to get it right. I'll point out that very few email clients get the rarely used "features" of RFC 822 correct. One of the reasons I didn't do a profile of RFC 822 dates is because the following is technically legal: Date: Wed, (nesday) 15(Hi There! \))Jan 1997 12:47 -0800 (PST) I bet most email clients would choke. Rarely used optional features are always bad for interoperability. They should either be mandatory or omitted.
So they get punished with bug reports and they don't deserve it better! They probably will also not understand the -00:00 or Z and will forget to accept the fractional seconds. That's no way to develop any quality software system.
Of course, the companies prioritize their bug fixes, and supporting the few people who use minute offsets falls low on the priority list. Yes it's bad software practice, but when Microsoft, Netscape, AOL, and every other big company does it, it's better to try to make the standard more robust for the cretins who seem to be the majority right now.
The "T":
- It simply looks ugly
- ISO 8601 defines both a syntax for a date field and for a time field, and protocol designers do not violate the standard if they transmit a date and a time field separated by a space character, the normal field separator in many systems. The T was provided where for some reason (sortability, atomicity, etc.) you want to keep the date and time in one single field on database systems that separate fields with spaces. I hope that we can get an explanation for the "T" along these lines into the next revision of ISO 8601.
I'm not yet convinced. I'm still concerned that this would simply be creating yet another date/time format. That's a very bad thing to do when there are already two existing standards to choose from. I'll concede that the "T" is ugly. I don't find the idea of "two fields separated by a space" convincing. We're defining a date-time format, and ISO 8601 includes only one date-time format. I want to do an ISO 8601 profile, not a new format which is vaguely ISO 8601 compatible.
The decimal comma:
- The decimal dot is clearly THE decimal separator dominating in
You have convinced me on this one. I'll update it in the next revision.
It would be great if we could get the format that Paul Eggert and I suggested being mentioned as a named profile in the next revision of ISO 8601. Then the RFC would only have tutorial function (repeat the definition of the profile and provide some examples, example code, and usage guidelines). I'd say, it is time that we get involved in the work on the next revision of ISO 8601.
I have no control over ISO 8601, no involvement in ISO, no knowledge of how someone gets involved in ISO, and no interest expending energy improving standards that people have to pay to read. Innosoft simply purchased ISO 8601 when we saw it being blindly referenced in new standards.
participants (2)
-
Chris Newman -
kuhn＠cs.purdue.edu