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

[Robert Elz]

    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 undefined.
    >  `+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.   They take special case
code to handle, and are a nuisance.   The -00:00 thing is a kludge
OK, but it is one that works.  Those few applications that actually
want to know that the local time isn't (wasn't) really UTC can
check for this, and recognise it, the vast majority which simply
want to convert the time given to some standard reference (for
collating, display in their local zone, etc) can simply parse
the -00:00 the same as they would 00:00 (or +00:00, whichever it
is) and don't need to worry about the difference, that the reported
time is in UTC is all that matters to them, not why it is.

While it is a kludge, it is a clever one.

    Date:        Thu, 02 Jan 1997 18:46:02 -0500
    From:        kuhn at cs.purdue.edu ("Markus G. Kuhn")
    Message-ID:  <199701022346.SAA01238 at ector.cs.purdue.edu>

    Excellent suggestion! This will make clear whether the timestamp was created
    in London or by a device that does not care about local time.

No, the +00:00 vs -00:00 can already achieve that, the 'Z' thing
isn't necessary.


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.
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.

kre