Re: [Emailcore] Time zones (was: Re: WGLC: draft-ietf-emailcore-rfc5322bis-03)

[Steffen Nurpmeso <[e-mail]>]

John C Klensin wrote in
 <17BB0479BF8EC86D09D8774D@PSB>:
 |--On Thursday, August 4, 2022 12:34 -0700 Russ Allbery
 |<[e-mail]> wrote:
 |> John C Klensin <[e-mail]> writes:
 |>> (1) Is it desirable to change 5322bis to allow a time zone to
 |>> express non-integral minutes?  From the discussion I think
 |>> the answer is "no", if only because these are supposed to
 |>> indicate actual time zones rather than being, e.g., precise
 |>> indicators of local time.
 |> 
 |> 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.  
 |
 |> It's of course possible that some government may introduce a
 |> time zone in the future with a non-integral offset because
 |> governments do some very strange things, but it doesn't seem
 |> likely enough to warrant trying to anticipate, at least to me.
 |
 |>From vague memory working with some UN ECOSOC agencies, it would
 |probably violate some international treaties.  I also don't
 |believe (although I have not gone back and checked) that it
 |would be allowed in an ISO date-time.  Those are things that
 |would probably give even governments inclined to strange things
 |pause, so the odds that it is worth anticipating --especially
 |given the risk of its being used for "clever" and confusing
 |purposes-- are, IMO, even lower.

I want to toss in that the IANA TZ is about to add information for
sub-second precision timezones.  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.

 |>> (2) Should "UT" be taken off the "obs-*" list and added back
 |>> into valid current syntax to allow systems to be clear about
 |>> what is intended, rather than having to guess at the intended
 |>> semantics of "+0000" and "-0000".  I still feel that might be
 |>> a good idea, but I'm not seeing much traction for it.
 |> 
 |> I'm not sure anyone who hasn't been deeply involved in the
 |> standards process has any idea that +0000 and -0000 mean
 |> different things,
 |
 |Agreed.
 |
 |> but I'm also not sure that adding UT will be
 |> any clearer or more likely to communicate to someone who isn't
 |> deep into reading the standards.
 |
 |I think I have given an example but cannot offer a convincing
 |argument that it would be understood by enough people often
 |enough to be worth the trouble.  But, just to be sure we have
 |thought about all the cases:  Setting aside the question of how
 |many recipients (or their MUAs) will both be aware of the
 |distinctions, suppose an originating system wants to supply
 |precise and interpretable time information for UTC time and,
 |ideally, communicate that they are doing that.   They can:
 |
 | (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.
 |
 |or, to go a bit further, 
 |
 |(iii) Use "UTC", which has never previously been valid, but
 |incorporate it into 5322 (and 5321) with a precise definition.

The IANA timezone will also have switched from "GMT" to "UTC"
after the next release, and the POSIX standard will come with the
string "UTC" predefined for the new field struct tm::tm_zone with
its next revision.

 |(iv) Give up on this splitting of hairs and the expectation that
 |others will admire the result and define a new, optional, header
 |field, e.g., "Precise-sending-date:" that would provide, and
 |precisely define with various keywords, whatever people are
 |trying to express, presumably even allowing exact location-based
 |time, Julian time, alternate calendars, exact latitude and
 |longitude if desired, etc.  If no one actually want to take that
 |seriously and do the work to specify it, I'm feeling a candidate
 |April 1 RFC --one in which it might be possible to express time
 |as an offset from when the horse that is being kicked died--
 |coming on.

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.

Thank you.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)