Re: [Emailcore] Time zones

[Russ Allbery <[e-mail]>]

Steffen Nurpmeso <[e-mail]> writes:

> I want to toss in that the IANA TZ is about to add information for
> sub-second precision timezones.

That decision was reversed after some additional discussion on the grounds
that it may cause problems for software that consumes those older time
zones while adding very little benefit.  The subsecond information is
being tracked in comments, but not generated as part of the database.

> Whereas it is not planned to change the regular format away from second
> precision, after the usual comprehensively skilled contribution from the
> Astronomer Steve Allen [1,2], where in [1] we can read

>   Millisecond agreement of broadcast time signals was not achieved
>   until the 1960s when they were based on cesium atomic
>   chronometers rather than direct astronomical observation

>   [1] https://mm.icann.org/pipermail/tz/2022-July/031726.html
>   [2] https://mm.icann.org/pipermail/tz/2022-July/031739.html

> which to me sounds as if there would have been a time for someone to use
> the real date and time of a location, it would be now.

I think you're using "real" in a way that may not align with how other
people think about date and time.  While solar time may be "real" in some
sense, the time that people agree to use in their day-to-day interactions
with others, including for email, is legal, not solar.  Steve's comments
were in the specific context of whether the millisecond precision of LMT
offsets in historical time zones had any real meaning, or were instead
excess precision.

> Since all this has started off with a software fix in a widely used
> software that wanted to avoid the loss of precision that is caused by
> the email standard on real world receiver systems, i would really like
> to see a sentence on timezones with sub-minute precision, and a guidance
> for software how this loss of precision on the receiver side can be
> avoided by enforcing UTC on the sender side as necessary.

To avoid all doubt, I explicitly oppose mentioning timezones with
sub-minute precision in an RFC about email.  No such timezones currently
exist, none are expected to exist in the future, and this would add
confusion without much benefit.

There have long been a small number of people who keep their system time
in TAI.  As someone who works in IT for astronomy, I have no idea why they
would voluntarily do that to themselves as it causes us no end of problems
in places that have to use TAI for various scientific reasons, but of
course you can do what you like on your system.  But TAI is not a
timezone, and I don't think it's a prevelant enough practice to warrant
addressing in an RFC that's already very long and complex.  The conclusion
that such a system should either convert the time to conventional local
time or to UTC before generating a Date header seems obvious from the
existing standard wording and capabilities, and whether or not such a
configuration and conversion is supported by a given piece of software is
not a standards question.

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