Thanks to all involved! The more of a delay the better on the one hand, but it is also clear that it has to be done *well* before November or even more serious problems would happen.
The extra time will allow us to figure out the best approaches both long-term and short-term, and give clients more time to adjust their implementations. I agree that more cooperation between CLDR and the TZDB groups would be very positive for the billions of people who are affected by both. While the vast majority of changes on both sides don't cause problems, there are definitely hard cases that pop up where additional communication would avoid problems. We both get hammered by governments that take precipitous actions without understanding the consequences! We'll try to keep you updated on what goes on in CLDR as this one plays out. Mark On Sat, Mar 7, 2026 at 2:00 PM Paul Eggert via tz <[email protected]> wrote: > After reviewing this thread's discussion, the consensus is to delay the > tm_isdst transition as requested, so I installed the attached proposed > further patch after talking with Tim. This patch contains a temporary > workaround for America/Vancouver timestamps between March 9 and November > 1 of this year. The workaround should accommodate CLDR's current > limitation, by marking these timestamps with tm_isdst as requested. The > plan is to remove the temporary workaround once CLDR is updated to > remove the limitation, which as I understand it can be done by a CLDR > release before November. > > Although not affecting CLDR, this patch also replaces the "-07" > placeholder abbreviation with "MST". No abbreviation choice is ideal > here, but "MST" appears to be the best of a bad lot. This abbreviation > can be updated once we find out what common practice does with > three-or-more-letter abbreviations. > > This patch removes any need for a TZDB release in the next couple of > days, as TZDB's proposed March 9 entry is now effectively a no-op and > there is no user-visible change in America/Vancouver's behavior until > November. However, we do need a new TZDB release sooner rather than > later because that November change must be user-visible, and TZDB > changes can take time to propagate to devices regardless of whether the > devices also use CLDR. So I'm thinking we wait for further comments and > release TZDB 2026b in a couple of weeks, or April at the latest - unless > some unrelated and more urgent data change comes up, in case we can > simply release. > > This episode is a bit of a wakeup call for the coordination between TZDB > and CLDR. Although in the past we've lucked out with similar changes in > Yukon and elsewhere, we will likely not be so lucky in plausible future > changes to timekeeping in North America, the EU, and other places where > people are considering abolishing DST transitions and changing time > zones and time zone names. Yesterday's email from Brian Inglis[1] > suggested that CLDR won't be able to accommodate the America/Vancouver > change until October, but I hope that's overly pessimistic as it will > surely take considerable time for the CLDR change's effects to be shaken > out in applications, and users will need to deal with timestamps planned > for November and later well before November rolls around. > > In short, the process for updating TZDB + CLDR surely can use more > streamlining. > > [1]: > > https://lists.iana.org/hyperkitty/list/[email protected]/message/BRP7ONFZU42SFR4TNRUWBBKOSVBBUCEN/
