If I remember correctly from my days programming my own software using the Geonames database and the Olson TZ database, the last time the US stayed on the same time change schedule year round was ww2.
A couple of small towns near me (I live in rural northern NY), used to have standard American flags hanging from every telephone pole. They've recently replaced them with the pictures of fallen war veterans, showing rank, and portrait. Could be that someone is trying to sell another world war soon. The US military doesn't like dealing with time confusion, especially in war time. On Wed, Jul 15, 2026 at 7:38 PM James Bellaire via tz <[email protected]> wrote: > 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. > >
