-00:00 on draft-newman-datetime-00.txt

Markus G. Kuhn kuhn at cs.purdue.edu
Fri Jan 3 02:46:47 UTC 1997


In message <9150.852255095 at munnari.OZ.AU>, Robert Elz wrote:

>     In message <199701022328.PAA05986 at 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 at cs.purdue.edu





More information about the tz mailing list