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

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

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

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

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

thanks,
   john