British Columbia redefines "Pacific Time"

British Columbia redefines "Pacific Time"

[Alan Coopersmith]

The Canadian province of British Columbia announced yesterday that they are:
  
   "Adopting permanent daylight saving time: ‘Spring forward’ on March 8
    will be the last time change, ending twice-yearly clock changes."

They've given us 8 months notice to deploy updates to timezone data before
their now-cancelled switch off of daylight saving time in November, but of
course, because naming is the hardest thing, they've decided that even though
their time will now be the same as Mountain Standard Time, they have
designated it as "Pacific Time", leading to the IANA TimeZone database folks
having a bit of discussion on what timezone labels to generate in output time
stamps:

https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/667WE5QTIA7MP2E7NC7T3SO7VLMZLVZS/

They've also pointed out the blast radius may reach a bit beyond their database:

> Ruby on Rails' ActiveSupport::TimeZone, for instance, attempts
> to "[l]imit the set of zones provided by TZInfo to a meaningful subset".
> It maps the string "Pacific Time (US & Canada)" to "America/Los_Angeles".
> The baked-in assumptions, once seemingly reasonable, now swiftly break down.
> https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html

-- 
         -Alan Coopersmith-                 alan.coopersmith@oracle.com
          Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Re: British Columbia redefines "Pacific Time"

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

Alan Coopersmith <alan.coopersmith@oracle.com> writes:

> The Canadian province of British Columbia announced yesterday that they are:
>     "Adopting permanent daylight saving time: ‘Spring forward’ on
>    March 8
>    will be the last time change, ending twice-yearly clock changes."
>
> They've given us 8 months notice to deploy updates to timezone data before
> their now-cancelled switch off of daylight saving time in November
> [...]

*Just* missed the 2026a release as well
(https://github.com/eggert/tz/commit/8b46071fd85a7a9434d63894bac64d30362cc16d),
I note it as I'd assumed the fix was in there until I checked.

> but of
> course, because naming is the hardest thing, they've decided that even though
> their time will now be the same as Mountain Standard Time, they have
> designated it as "Pacific Time", leading to the IANA TimeZone database folks
> having a bit of discussion on what timezone labels to generate in output time
> stamps:
>
> https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/667WE5QTIA7MP2E7NC7T3SO7VLMZLVZS/
>
> They've also pointed out the blast radius may reach a bit beyond their database:
>
>> Ruby on Rails' ActiveSupport::TimeZone, for instance, attempts
>> to "[l]imit the set of zones provided by TZInfo to a meaningful subset".
>> It maps the string "Pacific Time (US & Canada)" to "America/Los_Angeles".
>> The baked-in assumptions, once seemingly reasonable, now swiftly break down.
>> https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: British Columbia redefines "Pacific Time"

[Neal Gompa]

On Tue, Mar 3, 2026 at 6:28 PM Sam James <sam@gentoo.org> wrote:
>
> Alan Coopersmith <alan.coopersmith@oracle.com> writes:
>
> > The Canadian province of British Columbia announced yesterday that they are:
> >     "Adopting permanent daylight saving time: ‘Spring forward’ on
> >    March 8
> >    will be the last time change, ending twice-yearly clock changes."
> >
> > They've given us 8 months notice to deploy updates to timezone data before
> > their now-cancelled switch off of daylight saving time in November
> > [...]
>
> *Just* missed the 2026a release as well
> (https://github.com/eggert/tz/commit/8b46071fd85a7a9434d63894bac64d30362cc16d),
> I note it as I'd assumed the fix was in there until I checked.
>
> > but of
> > course, because naming is the hardest thing, they've decided that even though
> > their time will now be the same as Mountain Standard Time, they have
> > designated it as "Pacific Time", leading to the IANA TimeZone database folks
> > having a bit of discussion on what timezone labels to generate in output time
> > stamps:
> >
> > https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/667WE5QTIA7MP2E7NC7T3SO7VLMZLVZS/
> >
> > They've also pointed out the blast radius may reach a bit beyond their database:
> >
> >> Ruby on Rails' ActiveSupport::TimeZone, for instance, attempts
> >> to "[l]imit the set of zones provided by TZInfo to a meaningful subset".
> >> It maps the string "Pacific Time (US & Canada)" to "America/Los_Angeles".
> >> The baked-in assumptions, once seemingly reasonable, now swiftly break down.
> >> https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html

I am surprised they didn't go with a similar solution to the older
Indiana Eastern Time and call it "BC Pacific" or something similar.


-- 
真実はいつも一つ！/ Always, there's only one truth!