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/tz@iana.org/message/BRP7ONFZU42SFR4TN...