On 7/15/2026 5:56 PM, Paul Eggert wrote:
"Strange" is an understatement. Assuming the Navajo Nation stays in
sync with Denver, it'd mean "MST" would mean different things in
different parts of Arizona. I can't imagine that catching on in
popular use.
As Russ mentioned, RFC 822 and its successors (which your emails and
mine both conform to!) define "MST" to mean -07 and this won't change.
Also, it's not just email headers, as a good deal of software supports
RFC 822 style elsewhere. For example, in current GNU/Linux:
$ TZ=UTC0 date -d'2027-07-15 02:24 EST'
Thu Jul 15 07:24:00 UTC 2027
This result occurs because GNU 'date' hardwires "EST" to mean -05
partly so that people can parse RFC 822-style date strings. Hence if
the common meaning of "EST" changes in the US, then no matter whether
GNU "date" changes, some plausible uses will break.
I note that your email software modified the time on the post to your
time zone ... and omitted the zone: "On 2026-07-15 06:23, James Bellaire
via tz wrote:"
A post written at 6:23 PDT (9:23 EDT). Perhaps the zone should be
included so one can recalculate the time? My email software was
similarly unkind to your time zone: "On 7/15/2026 5:56 PM, Paul Eggert
wrote:"
If you quote this email it will appear that I replied before you sent
your post.
Inaccuracies built in to the system. An acceptable level of error?
Your software adding PDT and mine adding EDT to the sent time would help
... and with a given date one could reverse engineer the UTC. If the
parser is updated to use time zone history.
Lots of other programs have similar issues.
If GNU Emacs has this many issues in this area, it's daunting to think
of what issues other nontrivial packages have.
Hopefully this won't ruin a lot of programmer's summers.
