On 2026-07-15 06:23, James Bellaire via tz wrote:
It will be strange to see America/Phoenix define MST as -07 and America/
Denver define MST as -06.
"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.
Lots of other programs have similar issues.
I help maintain GNU Emacs and long ago went through it and fixed a bunch
of timezone issues. But even with that preparation, when I just now
scanned its source code for trouble in this area I needed to fix[1]
several documentation glitches, one of which indicates a potential
problem in real usage (GNU Calc's timezone arithmetic), and for which I
just now filed a bug report[2]. These glitches surely have encouraged
downstream users to run afoul of the proposed changes to "EST" etc.
If GNU Emacs has this many issues in this area, it's daunting to think
of what issues other nontrivial packages have.
[1]: https://lists.gnu.org/archive/html/emacs-diffs/2026-07/msg00124.html
[2]: https://bugs.gnu.org/81420
