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 on http://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. >
