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 <https://github.com/unicode-org/cldr/blob/edc66fb4354f8ee6debbcf94faeb5496b38a5982/common/supplemental/metaZones.xml#L737-L739> for America/Vancouver and here <https://github.com/unicode-org/cldr/blob/edc66fb4354f8ee6debbcf94faeb5496b38a5982/common/supplemental/metaZones.xml#L374> for America/Dawson_Creek, and for example French display names here <https://github.com/unicode-org/cldr/blob/edc66fb4354f8ee6debbcf94faeb5496b38a5982/common/main/fr.xml#L6203-L6216> .
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? On Fri, 6 Mar 2026 at 21:07, Paul Eggert <[email protected]> wrote: > On 2026-03-06 11:02, Robert Bastian wrote: > > 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. > > Unfortunately I'm not following. If the abbreviation is "MST" and > tm_isdst==0, what doesn't work? > > 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? >
