Re: British Columbia redefines "Pacific Time"

On Tue, Mar 3, 2026 at 6:28=E2=80=AFPM Sam James <[email protected]> wrote:
>
> Alan Coopersmith <[email protected]> writes:
>
> > The Canadian province of British Columbia announced yesterday that they=
 are:
> >     "Adopting permanent daylight saving time: =E2=80=98Spring forward=
=E2=80=99 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 bef=
ore
> > their now-cancelled switch off of daylight saving time in November
> > [...]
>
> *Just* missed the 2026a release as well
> (https://github.com/eggert/tz/commit/8b46071fd85a7a9434d63894bac64d30362c=
c16d),
> 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 outpu=
t time
> > stamps:
> >
> > https://lists.iana.org/hyperkitty/list/[email protected]/thread/667WE5QTIA7MP=
2E7NC7T3SO7VLMZLVZS/
> >
> > 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_Angele=
s".
> >> 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.


--=20
=E7=9C=9F=E5=AE=9F=E3=81=AF=E3=81=84=E3=81=A4=E3=82=82=E4=B8=80=E3=81=A4=EF=
=BC=81/ Always, there's only one truth!