Re: [Emailcore] Time zones

[John C Klensin <[e-mail]>]

--On Friday, August 5, 2022 10:59 -0700 Russ Allbery
<[e-mail]> wrote:

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

Part of that is that I can make an educated guess about how may
Internet email messages were sent out of Nepal in 1985 or
earlier.  I strongly suspect your guess would not be much
different.

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

Right.  And has also been pointed out, no matter what 5321 says,
-0000 has also been used as a notation for "I don't have a clue
what the time zone actually was/should be".

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

No disagreement there.  I think there is an argument for the
change.  I also think it is fairly marginal.  Not non-existent,
but marginal.  On the other hand, we could, in principle, add
the syntax back in (take it off the obsolete list) and explain
why (maybe in a sentence containing "MAY") in 5322bis, and then
put explanatory text into the A/S that would remind people that
"obsolete" is supposed to mean that originating systems should
not send it but receiving systems should not get too excited
about it.

thanks,
   john