In message <9150.852255095@munnari.OZ.AU>, Robert Elz wrote:
In message <199701022328.PAA05986@shade.twinsun.com>, Paul Eggert wrote:
> While we're on the subject, I think `-00:00' is a kludge and should be > removed. How about the following convention instead? > > `Z' means the time is in UTC and the local UTC offset is unknown or un
defined.
> `+00' means the time is in UTC and the local UTC offset is 0.
I'd very much prefer it if use of any kind of alphabetic codes for timezone indications were deprecated.
The 'Z' is not part of any deprecated code, it is the official ISO 8601 designation for times given in UTC. There are many applications where you are not interested in local time, and there, the 'Z' is a nice and short indicator that we use UTC. I do not like the idea to add a useless and ugly -00 in protocols where only UTC will be used. But a simple 'Z' to remind the casual viewer that this is UTC won't do any harm. Historically, the 'Z' was derived from a NATO letter time-zone code, which is considered in the computer community to be deprecated. This full code has been replaced by ISO8601's numeric offset notation. The lines of code to detect -00 or Z are practically identical, and a missing local time indicator is in any case a special case that has to be handeled. Forcing the programmer to add one extra check creates awareness! Automatic fall-through cludges like -00 just cause programmers to forget that this is a special case that might or might not need special consideration. For human viewers, I prefer a clearly visible distinction like Z and +00 instead of some hidden coding trick like -00 and +00 that is clearly outside the ISO 8601 format. We are discussing here about just one or two lines of code. If I have enough time, I'll write some nice generation and parsing routines for this format that we can put into the annex of the draft.
And while I'm here, it is all very nice to follow 8061 and all that, but if the aim of this draft is really to make a spec for reporting times that can be used on the internet, it is probably more important that the current internet time specs be examined, and needless differences be avoided. Eg: The rfc822 (e-mail) way to report a numeric time zone is +nnnn (or -nnnn) - no colons.
We go even one step further and remove the redundant minute offset digits. RFC822 has a relatively bad date/time format design. The original designers had only U.S. time zone abbreviations in mind, etc. I definitely wouldn't use it as any model for new designs. Including weekday indicators and 3-letter month names that have to be processed by a lookup table simply demonstrates that the RFC822 designers were careless here. RFC822 is anyway a very strange and difficult to read standard. The fact that it is widely used and quoted (or at least the subset of it that implementors understand ... ;-) does not mean that it is an excellent design. I was quite shocked when I read the famous RFC822 document the first time, and I have read a *lot* of bad standards before ...
There's about as much hope of that ever changing as there is of redefining time to use a much more rational 100 seconds in a minute, etc. Writing a spec that won't be used isn't very productive.
I do not agree here. We are not talking about changing RFC822. We are talking about an ASCII date/time format to be used in NEW protocol designs where there is no requirement for backward compatibility with RFC822. I claim that the RFC822 date format has been used in new protocols (e.g., HTTP), not because it is such a great design, but because it was easy to reference. Once a new and better format has been published, I am sure designers of new protocols will consider it. I had already plans to write something very similar to draft-newman-datetime and I very much appreciate this effort! Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu