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