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

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

--On Friday, August 5, 2022 20:12 +0200 Steffen Nurpmeso
<[e-mail]> wrote:

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

Regardless of the actual IANA action (thanks Russ -- I was
having trouble believing that would survive all the needed
scrutiny) I think you have made a very strong case that there
are situations and disciplines that need very high precision
time and ability to express zones to high precision as well.
Whether, without having read the articles yet, those are "time
zones" in the usual, conventional, person-on-the-street, sense
is a separate question, but one we don't need to answer today.
The question, instead, and at least as I see it, is whether it
is necessary (or even appropriate) to change the syntax of dates
in ordinary, standard, Internet mail to reflect that precision.
Doing so would have real costs with, not least among them, the
potential for legitimate messages to be rejected by receiving
MUAs (and maybe in-transit systems) that were sensitive about
syntax expressions and had not been upgraded.  Especially for
email systems that have been around for a very long time, our
success rate with getting rapid adoption when requirement have
been changed for reasons that are not clear and compelling to
almost everyone has been, well, terrible.
 
> 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.

Good information, especially after Russ's explanation is added
in.  Much as I would personally prefer to see "UTC" there to
trying to figure out what "-0000" means (and, as Russ pointed
out, most users, most of the time, will either not notice at all
or just shake their heads in confusion and move on), it is not
clear that it justifies a change to the email specs.  See above.

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

Steffen, the more I think about it, the more I think the wrong
question is being asked.  Either I am still not understanding
your explanations well enough or the "loss of precision" has
nothing to do with the 24 time zones established around 1884 and
skewed and adjusted many times since.   In addition, the
date-stamp in the email specs is supposed to indicate the date,
time, and location information, in conventional timekeeping,
when the (normally human) user pushed "send", "go", "ok" or
equivalent, about a particular message -- a process about which
seconds are good enough and for which we it was decided long ago
that more precise location-connected information than those
nominal 24 zones were not needed.   You are, as far as I can
tell, talking about a different set of assumptions, a different
set of requirements, and, to some extent at least, a different
timekeeping system.  That is not an extension to existing
practice, it is a fairly fundamental change to it, no matter how
simple the additional syntax seems to be.   Also as far as I can
tell and at least absent a very clear definition of how you are
using "as necessary", the only thing enforcing UTC on the sender
side would accomplish would be to lose the information, however
approximate, about the time of day at which a message was sent.
That implies an incompatible change to a great deal of software
as well as to the standards and a loss of functionality that
some (I'd guess many) users value, only to benefit what I'm
still guessing is a relatively specialized set of users and
applications.

Alexey's "non-starter" comment about covers that.  Like him I
believe it reflects WG consensus.  The recent notes from Russ
and John Levine reinforce that position and, IMO, strengthen the
"no change in format" one.  If anyone, other than me, would
still like to see "UT" taken off the obsolete list or "UTC"
added -- either with precise definitions that do not include
high-precision timezones -- let's figure out how to talk about
that, with the understanding that neither, especially the first,
is likely to break anything that now conforms to 5321 and 5322
("break" is different from allowing changes in practice).

Therefore, let's please stop talking about a change in the
syntax for "Date:", much less that for trace fields.  I suppose
one could safely change the latter with an SMTP extension, but
the practical result would almost certainly be that your
community would be able to talk only with each other --
presumably not what you have in mind.

Instead, let me expand on my other suggestion a bit, noting the
resemblance to John Levine's similar (and so far equally vague)
"Exact-Time:" header field and his separate idea about MIME
multipart/timestamped.   I also suggest that we take the idea
and discussion off of this list because it is clearly out of
scope for this WG.  Anyone who would like to be part of that
discussion other than Steffen and myself should speak up so we
can copy you.

Forget trying to modify either the syntax or semantics of any
existing header field or their components.  See if you can
define how and where the types of time stamp you are after would
be used for and by whom, not just what its syntax would be.
Define how and when that field would be applied, e.g., if you
are thinking about the time the message was sent, how that is
defined.  If you are really talking about high precision, should
there be syntax for ranges or confidence limits?  See if you can
think about what it would mean if the message were being sent
from a moving automobile, train, or plane or maybe even a
satellite or ship orbiting the earth or headed toward Mars.  If
location is part of the issue, think about whether to include
provisions for latitude, longitude, or something equivalent as
well.  Think, too, about other time scales: not just alternate
calendars (but not necessarily excluding them) but whether,
e.g., sidereal time rather than (or in addition to) solar time
might be useful.  If a message were sent from the surface of
Mars, would you want the time to reflect UT on Earth or some
flavor of Martian time?  Questions like that are not silly: a
corollary to the comments Russ, Julien, John Levine, and I have
raised about the costs of changing the existing date-time
definitions may suggest that, sooner or later, we will need to
cope with interplanetary or interstellar time and it probably
won't be via a small syntax change to "Date:".  If you need UT
or UTC at all, be sure to think about the difference and whether
that needs to be called out.    Ask whether the time stamp
applies to the whole message or to selected body parts and how,
if at all, you would want it to be affected by forwarding or
replying.  I have probably left some things out and you should
make the list longer as needed.

I assume that the answers to some of those questions are that
they are irrelevant (i.e., no one cares or that the data would
be useless) or that they make your head hurt and you just don't
see how to address them now.  That is fine, but it is also part
of the point.  To a considerable extent, the current email date
field and time stamps are useful precisely because their
semantics are not precisely defined and their precision (even in
the seconds of the time field itself, to say nothing of zones)
is fairly low.  The remaining questions and their answers should
tell you a good deal about necessary information and content and
about how to explain things to others.

Then, think about a new header field, more or less along the
lines John Levine and I suggested or, if this should really be
part of a signature over one or more body parts, whether to
handle that with a new MIME multipart content type or whether
you and the security folks should be talking about a signature
type that incorporates, not only information about the signing
key and a hash over the relevant material, but the precise date
and time the signature was applied (and whatever information is
needed with it).

As you are thinking about all of those things, think about at
least one more.  The advantage of a new header field over
modifying an existing one (or introducing a new multipart type)
is that mail systems --all the way out to the receiving MUA --
will ignore any header field they don't understand.
Implementers have decades of experience doing that and MUAs that
don't know how to do it have almost certainly disappeared.
However, if you are expecting implementers who are not part of
your team, discipline, or set of projects (or paid by them) to
support the field, there is a tradeoff: The more the field is
useful for a broad set of requirements, the more likely it is to
be implemented and supported.  However, the more complex and
hard-to-understand it gets, the less likely it is to be
implemented and supported.

I look forward to an Internet-Draft and would be happy to try to
help you with whatever issues you encounter... as long as it is
not on this list.

best,
  john