Subject: [Emailcore] Date/Time considered confusing

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Apr 2021 07:39:36 -0700

An essential bit of instruction, for the earliest days of 
interoperability, is the difference between canonical (protocol-based) 
representation, versus the creating local user, and possibly versus 
end-receiving user display.

For date/time, this maps to 'global time', local time for creator, local 
time for viewer and presentation style for viewer.

As was common during the 70s (and quite a bit since then), RFC 733 
sought to juggle all of these (except local time of viewer) into a 
single representation.

As noted, being able to display the string 'directly' can aid debugging. 
  This drove quite a bit of the protocol design then (and quite a bit 
since.)  The benefit of using a human-comfortable, simple text 
representation has been demonstrably /very/ helpful for the adoption and 
debugging of Internet protocols.  Requirements for special, 
protocol-aware translation software, in order to meaningfully display 
assorted protocol information, can be a significant barrier to adoption 
and use.

For date/time protocol use, the basic choice is whether to have the 
protocol-based information encode local time, indicating the offset or 
zone from 'global' time, or on 'global' time, indicating offset or zone 
for the creator's location.

In either case, offset/zone is essential, for mapping between author's 
local time and global time. An obvious issue for the choice is what will 
be the easiest and most accurate to work from, for the protocol 
(canonical) representation.

Historically (and possibly still) a challenge for some systems has been 
that they don't know their offset/zone.  The best they can give is 
whatever date/time is set manually for their system.  Whether a protocol 
should support use by such systems is obviously an important design 
consideration.  The challenge is to avoid being cavalier in that choice.

The mere fact that a protocol or format was designed a long time ago 
does not mean it needs to be replaced.  And displacing a specification 
that has been in global use for 45 years ought to set a very high bar 
and demand quite a bit of clear and compelling basis for replacing it.

In terms of emailcore, perhaps I have missed the clear and compelling 
statement of need, that fits within the charter, for pursuing email 
date/time format changes, within the context of this working group.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Michael Peddemors <[email-masked]>
Date: Mon, 19 Apr 2021 09:35:29 -0700

+1

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2021 14:19:56 -0400

>date/time format changes, within the context of this working group.

How do you feel about Ned and my proposal to use a minimal profile
of Date: in outgoing mail.

I agree we have to keep accepting all of the date formats that RFC 5322
allows but we can perhaps shrink the surface for errors.

I think on the modern Internet we can assume that anything that is
going to add a Date header knows the correct time since if you can
talk SMTP you can talk NTP and every phone and laptop I've seen in the
past decade includes an NTP client. Remarkably few people know what
time zone they are in which is why I would prefer to leave them out of
date stamps.

R's,
John

---

From: "Peter J. Holzer" <[email-masked]>
Date: Mon, 19 Apr 2021 22:52:28 +0200

> of Date: in outgoing mail.

I don't really see the advantage over the status quo.

> allows but we can perhaps shrink the surface for errors.

I don't think that it helps much. The day of week is competely
redundant, but it's also impossible to get wrong and the receiver will
almost certainly ignore it anyway. The time zone might be wrong, but if
it is wrong, then the computer's idea of global time is probably also
wrong, so using UTC doesn't help. And on the flip side, the time zone is
at least sometimes useful, so I think we would need a genuine advantage
for ditching it (I'm actually a bit irritated at senders which always
use UTC (cloud-hosted MS Exchange?)).

> time zone they are in which is why I would prefer to leave them out of

That seems a bit contradictory: NTP distributes a global time, not local
time. If you use NTP and get the timezone wrong, the time displayed by
your computer (or phone) will be wrong. People tend to notice that.
Before NTP was wide-spread people could set the wrong timezone, set the
correct local time and never notice that anything was wrong (except
maybe that time time would be wrong for a few weeks in spring until it
magically fixed itself). Now that's pretty much impossible. (Of course
some people will ignore that (just like they ignore the flashing 00:00
on their microwave), but given how much people rely on their computers
and especially phones, I'd guess that most would pester their "personal
IT-support" to fix it if they can't do it themselves.)

        hp

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

---

From: Steffen Nurpmeso <[email-masked]>
Date: Mon, 19 Apr 2021 23:35:08 +0200

Peter J. Holzer wrote in
 <[email-masked]>:
 |On 2021-04-19 14:19:56 -0400, John Levine wrote:
 |> It appears that Dave Crocker  <[email-masked]> said:
 ...
 |> I think on the modern Internet we can assume that anything that is
 |> going to add a Date header knows the correct time since if you can
 |> talk SMTP you can talk NTP and every phone and laptop I've seen in the
 |> past decade includes an NTP client. Remarkably few people know what
 |> time zone they are in which is why I would prefer to leave them out of
 |> date stamps.
 |
 |That seems a bit contradictory: NTP distributes a global time, not local
 |time. If you use NTP and get the timezone wrong, the time displayed by

As long as there is no reliable and gracefully accessible way to
get at TAI all this discussion is a bit off in my opinion.
What we would really need for computing would be CLOCK_TAI in the
standard, and TAI available everywhere.  UTC is a really great
thing, for humans, but computers and software just have no
interest in the sun.

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