I have always maintained that it is better for the members of this list to pick the time zone names because the people here are far more knowledgeable about these things than the politicians or the general public.
This is the wording that was placed into the British Columbia Interpretation Amendment Act back in 2019: > Pacific Time > 26 (1) In this section, “Pacific Time” means 7 hours behind Coordinated > Universal > Time (UTC). > (2) A reference to time in British Columbia is a reference to Pacific Time. This is the wording that was placed into the Yukon Interpretation Act in 2020: > (1) The Commissioner in Executive Council shall make regulations setting > standard time. > (2) Standard time shall be reckoned as the number of hours behind > Greenwich Time set by > regulations, and called Yukon Standard Time. > (3) Despite subsection (2), if the standard time set by the Commissioner > in Executive Council is > the same as Pacific Standard Time, standard time shall be called Pacific > Standard Time. The BC government in 2019 made an assumption that BC, Yukon, California, Oregon, and Washington would all make the same change at the same time on the same date. Clearly that did not happen. The BC government also believed it had the authority to redefine the term *Pacific Time* without consulting its neighbors to the north and south. The Yukon government then assumed in 2020 that BC, California, Oregon, and Washington would ultimately want to keep the term *Pacific Standard Time*, even though this conflicts with the naming convention introduced by the BC government the year before. Nobody really wants to be in a situation where there are different definitions of *Pacific Time* on either side of the Canada/USA border. And given that a single contiguous time zone will span most of Yukon and BC year round, there is no reasonable excuse for both BC and Yukon governments to label it with different names. The best way to help the governments and the public is to ignore any time zone names in the legislation. We already did this for Yukon. We can do it for BC too. Thus the TZ DB should call BC's new time zone what it is: *Mountain Standard Time* (or *MST*). This name has been used since 1883 in Canada, US, & Mexico to mean UTC-7. There are already seven TZ zones (not including links) that use UTC-7 year round. The TZ database currently assigns the abbreviation *MST* for all seven of these zones. Three of these zones are already used by areas in BC and one of those three is shared with Arizona. Assigning the string "*-07*" to *America/Vancouver* would make it inconsistent with other UTC-7 zones and would make it the only North American zone using a numeric offset rather than a standard abbreviation. For the sake of internal consistency and alignment with long-standing usage of MST to mean UTC-7, I favour *MST* over "*-07*". -chris On Tue, Mar 3, 2026 at 1:51 PM Paul Eggert via tz <[email protected]> wrote: > Thanks for the heads-up. I talked about this with Tim. Proposed patch > attached. We'll need a new TZDB release soon. > > I see two issues with the BC change. > > Legally, 21 hours after the long-planned 2026-03-08 02:00 transition > from PST to PDT, this change introduces a new transition from PDT to > Pacific Time that alters the tm_isdst flag and likely the abbreviation > but does not alter the UT offset. A 21-hour gap between two transitions > is small, so initially I thought of modeling things with a single > transition. However, zic and zdump work fine with a 21-hour gap so the > attached proposed patch follows the letter of the law rather than > simplifying it. > > No matter what abbreviation we use, there will be trouble. The obvious > abbreviation PT does not conform to the POSIX standard or to TZDB > guidelines, as it is one letter too short. The alphabetic abbreviation > least likely to break existing software is "MST", but that clashes with > the name "Pacific Time". The attached patch suggests some other > possibilities. I asked the BC government for guidance; if they do not > have a helpful suggestion I suspect "MST" will be the best of a bad lot > of alphabetic abbreviations, due to software compatibility issues. In > the meantime I installed into the development repository the proposed > patch, which uses a "-07" placeholder that also should work but is > jarring in a North American context. > > Comments welcome of course.
