Matt,
Thanks much, very helpful. I'm a little less worried about Windows now.
I'm still concerned about all the ramifications of the Sunshine
Protection Act.
-Brooks
On 2026-07-16 03:58 PM, Matt Johnson-Pint wrote:
This is a bit outside the scope of the tzdb, but with regard to Windows - I
worked a bit with the time zone folks at Microsoft during my time employed
there (a while back), so I can assure you that all the technical mechanisms
to handle such a change are already in place. As long as the government is
clear and provides sufficient notice, it won't be a herculean effort to
implement, and the team has been fairly responsive to changes elsewhere in
the world. Keep an eye onhttp://aka.ms/dstblog for official details.
Unofficially, the way this would likely go down is that legacy Windows TZ
registry data (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Time Zones) entries for US time zones would retain their
existing _identifiers_ (e.g. "Pacific Standard Time"), but the display
names would be updated (e.g. "(UTC-08:00) Pacific Time (US & Canada)"
=> (UTC-07:00) Pacific Time (US & Canada)" (in English - because display
names are localized, but IDs are not).
Interestingly, I don't see any mention of Canadian changes on their blog
yet. I suspect they could be waiting to see if the US aligns or not, to
reduce the required work.
Regarding CLDR, the current mappings in windowsZones.xml and metaZones.xml
are sufficient. America/Los_Angeles and America/Vancouver are both in the
America_Pacific metazone. However, a change similar to
https://github.com/unicode-org/cldr/pull/5439 for America/Los_Angeles might
need to be done - depending on whether the world starts calling -7 "Pacific
Daylight Time" or just updates the meaning of "Pacific Standard Time".
-Matt
On Thu, Jul 16, 2026 at 12:08 PM Brooks Harris via tz<[email protected]> wrote:
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.
