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. On Fri, 6 Mar 2026 at 23:38, Tim Parenti <tim@timtimeonline.com> wrote:
On Fri, 6 Mar 2026 at 17:01, Robert Bastian via tz <tz@iana.org> wrote:
All that ICU sees is tm_isdst=0.
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.
While I admit that whether the bulk of British Columbia is truly "changing zones" here is dependent on one's interpretation, it seems readily apparent to me that "friendly names" such as those provided by CLDR should *at least* be keyed on TZID and *calculated UTC offset* (with reasonable fallbacks) to ensure they don't break if and when a true zone change occurs. The vagaries of the obsolescent tm_isdst flag needn't factor into this equation.
I'm also interested in which legislation you saw that says this change to "Pacific Time" happens at midnight on Monday?
The Order in Council effectuates the legislative changes from Monday 9 March 2026. https://www.bclaws.gov.bc.ca/civix/document/id/oic/oic_cur/0063_2026 So, legally, the change from 02:00 Pacific Standard Time to 03:00 Pacific Daylight Time occurs as usual on Sunday, and the new legal name for the zone takes effect 21 hours later at the start of the day on Monday along with the repeal of BC's legal framework for DST. This is a strong reason for modeling the data as we presently have it drafted.
I note that we initially took the exact same approach in tzdata for Yukon in 2020 (albeit mistakenly at first). We had (incorrectly) understood that the Yukon press release published 2020-03-04 described a "done deal" effective 2020-03-08. While we did not rush to release then, as wall clock times would not diverge until 2020-11-01, release 2020a, dated 2020-04-23, reflected our then-understanding of Yukon's change and published MST with tm_isdst=0. We later found out that the change wouldn't actually take legal effect until 2020-11-01, so release 2020b, dated 2020-10-06, retroactively applied PDT and tm_isdst=1 back to the 2020 DST period until the 2020-11-01 change. https://mm.icann.org/pipermail/tz/2020-July/029161.html https://mm.icann.org/pipermail/tz/2020-September/029281.html https://mm.icann.org/pipermail/tz/2020-September/054318.html
So, a system taking tzdata updates promptly would have seen the following for America/Whitehorse in 2020:
- To start the year: UTC−8, PST, tm_isdst=0 - From 2020-03-08: UTC−7, PDT, tm_isdst=1 - From ≥2020-04-23 (2020a update): UTC−7, MST, tm_isdst=0 - From ≥2020-10-06 (2020b update): UTC−7, PDT, tm_isdst=1 - From 2020-11-01: UTC−7, MST, tm_isdst=0
All of this back-and-forth with tm_isdst transpired without issues being raised at the time.
-- Tim Parenti