Re: [Emailcore] Time zones

[Russ Allbery <[e-mail]>]

John C Klensin <[e-mail]> writes:
> Russ Allbery <[e-mail]> wrote:

>> There are historic time zones that have offsets of non-integral
>> minutes, but generally these are attempts to represent local mean time
>> (LMT) from eras before standardized time zones and thus only involve
>> historic time stamps.  It's hard to see how these would be relevant to
>> the definition of the Date header in email (or netnews) messages.  I
>> think there may be a few areas of the world with relatively late
>> transitions from LMT, possibly as late as the 1970s in exceptional
>> cases (I cannot remember off-hand), but the overwhelming majority of
>> such zones only make sense for times prior to the invention of email.

> Well, the invention of email goes back to the mid-1960s, but I think the
> point is still clear.

My understanding is that nearly all of the world switched off of LMT in
the 1920s and 1930s.  I was wrong about the recency of the last case:
Nepal only switched off of LMT (with a UTC offset that included seconds)
in 1986.

So *arguably* a correct representation of an email message sent from Nepal
in 1985 would require a non-integral minute offset to represent the local
time zone.  In practice, this doesn't seem like something that the email
standards should worry about, as the only relevance I can think of
off-hand would be instructions for how to parse historic email archives
that might contain such a message, and I'm dubious that's how the message
would have been generated at the time.

>  (i) Use "-0000" and hope the recipient will figure out that it
> means UTC and no an odd way to write a zero offset.  They would
> face the small challenge of there being cases elsewhere of -0000
> being used with other semantics, so we would essentially want to
> say "whatever you have been using "-0000" for before, it means
> UTC and nothing but UTC".

>  (ii) Use "UT", hoping that the recipient (or other senders)
> will not still be using to to mean "GMT with summer time at
> right time of year" which might have been confusing, but valid,
> prior to RFC 5322 making it obsolete.

Ah, I see your point: UT makes it clearer that the sender was intending to
convey that the time was intentionally in UTC, whereas -0000 may be
confused with +0000 and thus attempting to convey a local time zone that
happens at the moment to coincide with UTC.

I can see the possibility of conveying an extra small amount of
information and agree that UT is clearer than -0000 in that sense.  I'm
personally dubious that it's worth reversing marking something as
obsolete.  If there were a theoretical implementation that chose not to
implement that part of the standard because it was marked as obsolete,
this feature doesn't seem compelling enough to warrant telling them that
they now need to add UT to their date parser.

-- 
Russ Allbery ([e-mail])             <https://www.eyrie.org/~eagle/>