On 2026-07-15 07:37 PM, James Bellaire via tz 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.
As James said earlier "Of course, the bill still needs to pass the
Senate. So we are borrowing problems from the future". But shouldn't we
be prepared for this possibility?
One thing I wonder about is how Windows might handle this. Their display
names all start with the primary UTC offset, for example "(UTC-05:00)
Eastern Time (US and Canada)". This format has been used for decades,
like since Win2000, maybe NT4.
So, apparently, by the Sunshine Protection Act (the Act), the UTC offset
portion would presumably be "(UTC-04:00)", they might retain"Eastern
Time" and "US". But what if Canada does not follow the USA changes?
What about all the timestamps made from (UTC-05:00) Eastern Time (US and
Canada)? Seems they'd need to maintain some method for reverse
compatibility, possibly leading to two lists of display names.
As I understand it, the mapping from TzDb identities to Windows display
names is made through CLDR:
https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplemental/metaZones.xml
How would this accommodate the change from the Act? Seems like you'd now
need two levels of lookup, possibly two metaZones.xml files?
The time zone and DST metadata is held in the Windows Registry. How will
this mapping be handled there?
I feel all these technical difficulties created by the Sunshine
Protection Act are dangerous and the Senators who may vote on it are
probably mostly unaware if it. It all looks extremely problematic to me.
I think every sector of society, including "big tech", should be very
concerned about this.
