Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc5322bis-03

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

--On Monday, August 1, 2022 22:10 +0200 "Peter J. Holzer"
<[e-mail]> wrote:

> On 2022-08-01 14:50:51 -0400, John C Klensin wrote:
>> --On Monday, August 1, 2022 19:43 +0200 Steffen Nurpmeso
>> <[e-mail]> wrote:
>> > The user uses a TAI timezone locally, a timezone where the
>> > offset from UTC has second precision.  This is a quite
>> > common situation for at least past timezones, too:
> 
> [...]
> 
>> As far as the seconds themselves, 5322bis defines time as
>>      time-of-day zone
>> and time-of-day as
>>      hour ":" minute [ ":" second ]
>> 
>> So I don't understand the problem.
> 
> It's not about the time, it's about the time zone. The user is
> apparently using a time zone which is non-integral number of
> minutes from UTC (not sure why someone would do that). So for
> example, if I was a time traveller who wrote an email from
> Vienna in 1900, my offset from UTC would be 1 hour, 5 minutes
> and 28 seconds, so I would need to construct a date header like
> 
>     Date: Mon, 01 Aug 1900 22:01:31 +01:05:28
> 
> except that that's not valid RFC5322 syntax ((FWS ( "+" / "-"
> ) 4DIGIT) / obs-zone).

Ah.  That makes it much more clear.  Thanks.  But, since the
standardization of time zones and the associated international
system, there are no zone on non-integral minutes  (or even,
IIR, granularity finer than 30 minutes).  The time zone
specification is not an indication of location, it is an
indication of, well, time zone.  Trying to diddle the time zone
in order to reflect TAI times (or anything else) would fall into
the "horrible kludge" category.  I'd guess the above, even
without  the ":28" part, would break a lot of receiving MUAs.

As far as receiving MUAs converting time stamps to the local
time and zone, I repeat -- not an IETF problem (and, even if it
were, it would be out of scope for this WG) and they should do
whatever their users and implementers do.  From a MTA and
Submission server standpoint, my sense is that we are better off
if they believe whatever the originating MUA tells them and just
passes it along (I suppose a Submission server receiving a
message without a Date: header field could either supply
whatever it thinks is local or UTC).

I may be unique, but, if a user in, e.g., +0400 sends me a
message at 02:00, I'd prefer that my MUA leave that alone rather
than standardizing to UTC because known that the sender composed
and sent the message at 2AM is useful information for me (hence
the suggestion about comment fields)

>> (3) Add a sentence or two similar to Steffen's above or
>> something that indicates that "UT" really indicates UTC at the
>> time the date-time was inserted in the message, i.e., that, if
>> compared to UTC six months earlier or later, they would be six
>> months apart, not six months maybe plus or minus an hour or
>> so.
> 
> I don't think that would make any difference for comparisons. 
> 
> 1 Aug 2022 19:39:03 UT would specify exactly the same point in
> time as 1 Aug 2022 19:39:03 +0000 or 1 Aug 2022 15:39:03 -0400.

For comparisons, it absolutely don't.  However if a user sends
out a message that says, e.g., "next meeting same time next week
as the time this message was sent" in the wrong place and at the
wrong time of year, that could be the same time or an hour
earlier or later, depending.  My recollection is that SEDATE is
trying to figure out how to handle that issue.  From our
standpoint, other than _maybe_ allowing UTC to be specified
explicitly, I think the best strategy is to try to explain to
such users, when the opportunity arises, that saying things of
that sort to an international audience is going to cause
problems... and then we move on.

> The only difference between 19:39:03 UT and 19:39:03 +0000
> would be that the latter could be assumed to be local time (so
> we can take a (very rough) guess at their location, and also
> that they were staying late at the office) while the former
> gives no such information.

Exactly.  See above.

> I'm not sure how useful that is. A system can already convey
> the same information by using "-0000" as the offset. "UT" is
> marginally more readable, but you'd have to read the RFC
> anyway to be sure about the semantics.

If systems actually did that and users understood the
convention, so that your example above would read "... 19:39:03
-0000 and 19:39:03 +0000 ...", the notion of used "UT"
explicitly would be moot.  My experience, which is by no means
universal, is that very few systems actually use -0000 that way
and that proportionately even fewer users understand what it is
intended to convey.  YMMD.

   john