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

["Peter J. Holzer" <[e-mail]>]

On 2022-08-03 01:14:08 +0200, Steffen Nurpmeso wrote:
> John C Klensin wrote in
>  <305AE7DFC0554733F7C75AAD@PSB>:
>  |--On Monday, August 1, 2022 23:17 -0400 John Levine
>  |<[e-mail]> wrote:
>  |> It appears that John C Klensin  <[e-mail]> said:
>  |>> 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)
>  |> 
>  |> I don't think you are, but that is definitely between you and
>  |> your MUA, which can display dates any way it wants, not limited
>  |> to anything defined in RFC 5322.
>  |
>  |Well, it can display them any way it wants (which is what I said
>  |before at least twice, so we agree) but only if it has adequate
>  |information.  If the MUA at the sending end, or any MTA in the
> 
> You were talking about time zone standardization, but this is all
> politics.  A very large amount of the world population even live
> in calendars that are not comparable to Gregorian date.

Other calendars are IMHO firmly outside the scope of RFC5322. The
purpose of the Date header is to convey the point in time when the mail
was "complete and ready to enter the mail delivery system". A MUA can
convert that to the user's preferred system for display purposes, but
there is little value in actually transmitting dates in different
calendar formats over the wire. Like several people here I find the
usage of localtime+offset occasionally useful (was that mail sent in the
middle of the night?), but I don't see what extra value I could gain
from knowing that the sender preferred to use the islamic calendar. That
just adds extra complexity. (If I designed a new protocol from scratch
I'd probably just use UTC.)

> It can change at any time.

Some changes are likely (e.g. DST switch times), some less likely but
happen occasionally (e.g. changing the time zone), some are technically
possible but very unlikely (e.g. a timezone with an offset which isn't a
whole round number of minutes, or a switch to a completely different
calendar system).

> Giving a sentence of advise for these cases seems a viable and
> advisable change in my opinion.

There is an infinite number of "what if" scenarios. I don't see why we
should advice on scenarios which are theoretically possible but
extremely unlikely. The RFC is (IMHO) already too long.

>  |path, changes a time that was originally expressed locally to
>  |UTC (or to its own local time), then the receiving MUA doesn't
>  |have enough information to reinterpret the time back to the
>  |sender's time.   And I really hope this does not lead to a
> 
> The internet message format is it that does not offer sufficient
> methods to cover the time zones of the world.

It does. Which timezone (real, official timezone, not just something
someone decides to implement on their private PC) has an offset of a
non-intergral number of minutes? TAI is not a time zone.


> My question or suggestion was _solely_ whether the standard wants
> to throw words towards the "-0000" that the RFC mentions as
> 
>   Though "-0000" also indicates Universal Time, it is used to
>   indicate that the time was generated on a system that may be
>   in a local time zone other than Universal Time and that the
>   date-time contains no information about the local time zone.
> 
> because the widely used MTA exim does not do that (or did not when
> the patch was committed in 2020, i did not look at the current
> code base).

What additional words would you propose and why would you think that
those words would have persuaded the Exim maintainer when the existing
words did not?

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | [e-mail]         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"