Some background information inspired by some of the discussion. > The simplest fix appears to be to change to the abbreviation "MST", as is > already the case for America/Vancouver's geographic neighbors that > observe UTC-7 all year. This should fix the CLDR issue (albeit in a > different way than what you suggested)
1. CLDR (and the software that uses it) does not use the TZDB abbreviations at all; it only depends on the timezone ID, and the offsets & tm_isdst flags produced by the TZDB rules. 2. CLDR provides support for 6 formats for time zone names, and four of those have long and short forms: so 10 combinations. ( https://unicode.org/reports/tr35/tr35-dates.html#using-time-zone-names). There is curated data to support the construction of these formats for all of the current* time zones for over 100 languages. The names (long and short) for each timezone are chosen to match as closely as possible what is used in each language (with possible country variations as well). The first of those formats is "Generic non-location format", like "Pacific Time". A meeting that happens at "13:00 Pacific Time" means that it happens at different UTC times during the summer and winter; it is driven by the wall time in a metazone spanning the multiple timezone IDs that use something called "Pacific Time". Using the name "Pacific Time" for both a fixed time and one that observes daylight savings will clearly cause confusion among people all over the US and Canada (and beyond). > Downstream users are advised to update CLDR if they update TZDB. 3. CLDR is used in essentially all* consumer-facing mobile phones, desktop/laptop operating systems, and many other products. Most of those products have mechanisms to update to a new version of the TZDB data tables; however, many of them do *not* have mechanisms to immediately update the CLDR data. One can 'advise' users as much as one wants, but the facts on the ground are that for months (with some products, many months), if the tm_isdst flag is flipped, people will see "Pacific Daylight Time". As Robert said, "CLDR releases don't propagate as quickly as TZDB releases". The best we could probably do is advise all products using CLDR directly or indirectly to either not update to the TDBC data release, or to patch the tm_isdst flag. 4. The population of people living in the region covered by America/Vancouver is roughly 100 times the population of Yukon; so an approach taken for the latter doesn't necessarily scale to the former. (And of course, the population indirectly affected is far greater than the population of BC.) Mark On Fri, Mar 6, 2026 at 2:11 PM Paul Eggert via tz <[email protected]> wrote: > On 2026-03-06 12:47, Robert Bastian wrote: > > > 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. > > > 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. > > We have a law and a press release from the BC Attorney General's office > saying "Pacific Time". 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. > > How about this idea? > > 1. CLDR puts out a new version or patch today that outputs the name > "Pacific Time" for America/Vancouver timestamps starting March 9, > regardless of whether the tm_isdst flag is 1 or 0 for those timestamps. > The idea is that this new CLDR version will work for America/Vancouver > regardless of whether the associated TZDB version is 2026a or 2026b. The > spelling of the string "Pacific Time" is entirely up to you; if you > prefer "Pacific Daylight Time" then by all means use that. > > 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. > > Would that work for you? Quite possibly the "today" is a bit fast but > the point is that we should not wait for months to get going on this. > The ship is sailing Monday, not in November. Putting things off is not a > good strategy. > > > > I'm also interested in which legislation you saw that says this change to > > "Pacific Time" happens at midnight on Monday? > > The name "Pacific Time" is specified by the Interpretation Amendment > Act, 2019, SBC 2019, c 41 <https://canlii.ca/t/55ht0>. That act comes > into force on Monday, March 9 by BC Order In Council 36/2026 > <https://www.bclaws.gov.bc.ca/civix/document/id/oic/oic_cur/0063_2026>. > The OIC does not specify time of day, which means it comes into force at > the start of the day; see > < > https://www.bclaws.gov.bc.ca/civix/document/id/consol15/consol15/00_96238_01#section4 > >. > >
