... correction - I meant, whether colloquially we still say "Pacific Daylight Time" (ie, "permanent daylight time"), or if we say "Pacific Standard Time" even though it's now -7 instead of -8.
On Thu, Jul 16, 2026 at 12:58 PM Matt Johnson-Pint < [email protected]> 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 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. >> >
