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