Our issue is not with abbreviations (-07/MST), and changing the abbreviation to MST will not fix the issue. ICU checks whether a rule applies (tm_isdst), and chooses the DST name if one does.

A change that would be compatible with current CLDR data is:

Rule Vanc 2026 only - Mar 9 0:00 1:00 D
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone America/Vancouver -8:12:28 - LMT 1884
-8:00 Vanc P%sT 1987
-8:00 Canada P%sT (any time before 2026-11-01)
-8:00 Vanc (P%sT, MST, -07, whatever)

This keeps tm_isdst true for eternity; that's obviously not ideal, but we can come back and fix this when we know more, and when CLDR can handle such a change.

On Fri, 6 Mar 2026 at 19:39, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2026-03-06 08:11, Robert Bastian via tz wrote:
> Because CLDR keys its display names by this flag, this change will cause ICU and
> other downstream software (including major operating systems) to display
> BC’s UTC-7 as "Pacific Standard Time," while Los Angeles’ UTC-7 will
> display as "Pacific Daylight Time."

Yes, and what's currently in the draft TZDB on GitHub (America/Vancouver
switching to abbreviation "-07") was intended to be merely a
placeholder. We weren't intending to publish it as 2026b.

For the reason you mention and for other software-compatibility reasons,
let's change the "-07" placeholder to an alphabetic abbreviation. 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), and should be good enough until
the BC government and/or common practice advises us all later on what
three-or-more-character abbreviation is most popular.

Of course we'd prefer to make just one change now, and no changes later,
but it seems we do not have that luxury given the rushed way this was
done legally. And I would rather publish something before the actual
legal change occurs on Monday, rather than issue a post-facto change.