> > CLDR tries to match common usage, and common
> > usage of "Mountain Standard Time" for UTC-7 in BC has just not been
> > demonstrated.
>
> I assume you meant "in America/Vancouver" not "in BC", as "Mountain
> Standard Time" has long been common usage in some parts of eastern BC.
Either really. The share of the BC population that is currently on MST is tiny, it doesn't shift the scale for "common usage".
> Unfortunately if we wait for common usage to be demonstrated for the
> Vancouver area we'll have to wait for months, and for reasons I hope are
> obvious we shouldn't do that - certainly not until November.
These reasons are not obvious to me. We have a perfectly good name that we can continue using until November.
> We have a law and a press release from the BC Attorney General's office
> saying "Pacific Time".
The press release also says things like "People and businesses will have eight months to prepare for Nov. 1, 2026, when clocks would usually be turned back, but now will remain the same. At that point, the transition to Pacific time, the name of B.C.’s new time zone, will be complete." I get that TZDB puts a lot of value on following some law to the letter, but the BC government has explicitly announced this summer as a transionary period, so I don't understand why you have to release this change 5 days later if a major library is telling you that this will break them.
> So my guess is that CLDR will go with "Pacific
> Time" for now, and then change later if a different name evolves. Of
> course these details are up to CLDR.
I think I have explained in detail what CLDR is doing and why.
> 1. CLDR puts out a new version or patch today
> 2. TZDB puts out a release 2026b today that changes tm_isdst to 0.
> 3. Downstream users are advised to update CLDR if they update TZDB.
That's not feasible. TZDB updates are basically immediate in most major systems, whereas CLDR/ICU updates take weeks, if not months, to propagate to devices.
> If that is true, then that is an extremely brittle design decision in the face of outright zone changes — one which needs some re-evaluation regardless of the proximal situation or how it is resolved.
It is, and Unicode's next-gen library, ICU4X, whose timezone code was mostly my design, does not do this and won't break. However, ICU puts a lot of value on backwards compatibility, i.e. updating timezone data for old libraries, which is why this is a very hard issue to fix, and it "mostly works", because we usually get more than a week's notice for such an impactful change.
> I note that we initially took the exact same approach in tzdata for Yukon in 2020
> All of this back-and-forth with tm_isdst transpired without issues being raised at the time.
I was not working at Unicode in 2020, so I don't know exactly how this was handled. I know, however, that we used "Yukon Standard Time" as requested by the Yukon government, for which we luckily already had translations for the pre-1984 zone, and which does depend on tm_isdst. I'm sure this was a lot of work for us regardless, and it might have even broken users – keep in mind that the population we're talking about this week is 100x that of the Yukon.
In the end, I can't make you do anything. We decided that we should ask you to take this into consideration, but that seems to have failed. I have better things to do with my weekend (Europe/Zurich here), so thank you for your time, and we will go with option 2, which is to ship a patched TZDB in ICU.