How to Patch BC Permanent DST March 8, 2026

The Canadian province of British Columbia enters daylight saving time for the last time - your server doesn't know that yet.

Today, March 8, 2026, British Columbia clocks spring forward to Pacific Daylight Time as they do every year. The difference this time: they are not coming back. The BC government has legislated that the November fall-back - the one that was supposed to happen on November 1, 2026 - will not occur. BC will remain on PDT (UTC-7) permanently.

For the average resident, this is a headline about not changing clocks. For every developer running timezone-sensitive software on a BC server, it is a quiet data integrity bomb with a detonation date of November 1, 2026.

Let's Be Honest About What the Government Is Actually Doing

The official framing is "eliminating the inconvenience of clock changes." That sounds like progress. It is not. It is a political choice dressed up as a scientific one.

DST itself is a patch — a correction applied twice a year to reconcile civil time with daylight. If the premise is that this correction is unnatural and disruptive, the honest solution is to stop entering DST entirely and stay on standard time year-round, as Arizona does. Arizona's choice has geographic logic behind it: proximity to the equator means the difference in sunrise and sunset between seasons is modest. The adjustment was never worth the disruption.

BC has no such justification. Instead, the government is choosing the version of the patch people like more — the bright summer evenings — and locking it in permanently. They cannot wait until November to exit DST gracefully, and they cannot get their act together to skip the spring-forward entirely. So they are doing the worst of both: entering DST today as always, creating a false spring transition in the timezone database, and betting that nobody notices the asymmetry.

BC will effectively become the new Arizona of Canada — permanently misaligned from standard time — without the geographic reasoning that made Arizona's decision defensible. The crowd is pleased. The infrastructure is not prepared.

What Breaks on November 1, 2026

Every standard timezone database — the IANA tzdata that PHP, Go, Python, Java, and every major runtime uses — currently describes America/Vancouver as a zone that springs forward in March and falls back in November. That definition was correct for decades. After today it is wrong, but the database does not know that yet.

On an unpatched server, run this PHP script after November 1, 2026:

Expected output on a patched server: 02:00:00 (02:00 AM PDT, DST still in effect)
Actual output on an unpatched server: 01:00:00 (01:00 AM PST, fell back as if nothing changed)

That one-hour difference silently corrupts every timestamp that crosses November 1. Bookings, scheduled jobs, log correlation, billing records — anything that stores a unix timestamp and displays it to a BC user is now off by one hour. The inputs are correct. The output is wrong. The server is confidently lying.

DST Is Not New Territory for Gyroscope

Gyroscope has been articulate about timezone handling since 2015, when Gyroscope 7.1 introduced explicit DST awareness in the time picker. On a spring-forward day the skipped hour (2:00 AM) is removed from the picker entirely. On a fall-back day the repeated hour (1:00 AM) is shown twice with a clear visual indicator. These are not cosmetic niceties — they are the difference between a user picking a time that does not exist and one that is genuinely ambiguous.

What BC's change means for Gyroscope is straightforward: from November 1, 2026 onward, the time picker for any BC date must show a clean, uninterrupted list of hours. No repeated 1:00 AM. No fall-back indicator. The DST clock icon should remain active all the way through winter because BC is, technically, still in DST.

Getting that right requires the server to be running patched tzdata. Without it, the picker will show the phantom fall-back — a 1:00 AM repeated slot on November 1 that will never happen.

Patching the Timezone Database

The IANA tzdata format allows you to define custom zone rules using a .zi source file. The compiled binary is a standard TZif file that your OS, PHP, and Go all understand natively.

The rule is simple: define a spring-forward for every March from 2026 onward, and define no fall-back. Once the clocks go forward in March 2026, the DST save is never reversed.

Compile

Verify — you should see the Mar 2026 spring-forward and NO Nov 2026 fall-back

Apply

After the patch, verify with PHP:

Expected output — all four hours must show DST=1:

Verifying with Gyroscope

The Gyroscope date picker provides an immediate visual sanity check. Open it on November 1, 2026. On an unpatched server you will see a duplicate 1:00 AM slot — the phantom fall-back the database still believes in. On a patched server, the hour list is clean and continuous, with DST indicators present throughout.

The Gyroscope system diagnostics page also includes a dedicated test for this, listed as BC Permanent DST Patch. It loads America/Vancouver directly and checks unix timestamp 1793523600 — the exact moment the clocks should have fallen back. A patched server returns 2026-11-01 02:00:00 PDT -07:00 (DST=1). An unpatched server returns 2026-11-01 01:00:00 PST -08:00 (DST=0). The result is displayed as OK or FAIL alongside all other system health indicators.

The Deadline Is November 1, 2026

Today is the day the asymmetry was created. November 1 is the day it breaks things. That is eight months from now — enough time to patch every server carefully, verify the output, and not be surprised when the fall-back that the database expects simply does not happen.

The patch takes about two minutes to compile and apply. The debugging session on November 2 when a BC client reports that timestamps are off by an hour will take considerably longer.