All that ICU sees is tm_isdst=0. The link between time zones and their "metazone", which determine display names, comes from CLDR. See
here for America/Vancouver and
here for America/Dawson_Creek, and for example French display names
here.
Linking Vancouver to Mountain Time names would require a CLDR release, which would definitely not reach devices by Monday, and more importantly, is not actually what we want. CLDR tries to match common usage, and common usage of "Mountain Standard Time" for UTC-7 in BC has just not been demonstrated. Changing BC to Mountain Time names next week is going to confuse end users, especially if we then change to yet another name in a few months. If it turns out that Mountain Standard Time is the best display name for BC, we will update our mapping to select Mountain Standard Time, but for now we want to keep Pacific Daylight Time.
> Several timezones do exactly that already: America/Dawson,
> America/Whitehorse, America/Dawson_Creek, America/Fort_Nelson,
> America/Phoenix, America/Hermosillo. Many of these timezones made a
> change in a past year that is pretty much what America/Vancouver is
> doing this year. If they don't work why not? and if they do work then
> what's different in this new case?
Many of these time zones were newly created in the TZDB when they changed their offset. If that happens, ICU will just display the offset, which isn't great, but at least it's not showing a wrong name. We usually also had more than a week's notice to deploy these changes, and it was usually obvious what names to use.
I'm also interested in which legislation you saw that says this change to "Pacific Time" happens at midnight on Monday?