What BC’s Permanent Clock Change Did to My Demo OCI DBCS Database

I want to walk through this the way it actually happened, output by output, because the whole story is sitting in the outputs. If you run Oracle on a British Columbia (BC) host, you will want to run the same handful of checks, and it really helps to know what each line is telling you before you panic or relax.

Here is the background in one breath. BC sprang the clocks forward on March 8, 2026, and that was the last time it will ever do it, no more fall-back. The province stays on UTC-7 all year now and calls it Pacific time. Sounds like good news, and for a normal person it is. But every server you own still has the old “fall back on the first Sunday of November” rule buried inside it, and unless something taught it otherwise, it is still planning to fall back on November 1. On a date that legally no longer has a fall-back.

So I poked at a demo box. Oracle Linux 8, a single-instance 19c Standard Edition 2 database, nothing special. Here is everything I ran and what each piece actually meant.

First Look: Is This Box Even Affected

That one line told me most of the story already. The tzdata package is where Linux keeps every timezone rule in the world, and this copy is version 2023c. The BC change did not show up in tzdata until version 2026b. So this box is running rules that are three years too old to have ever heard of permanent Pacific Time. Left to itself, it will do the old November thing.

An old version number on its own is not proof, though. I wanted to watch the box get November wrong with my own eyes, not just assume it from a package name. So I asked it a very pointed question.

I picked a moment safely past the November boundary, December 1 at 20:00 UTC, and asked what that instant looks like on a Vancouver wall clock. If the box knew about the BC change, it would answer in permanent daylight time, UTC-7, which would be 13:00. Instead, it came back 12:00 PST, offset UTC-8. That PST is the giveaway. The box still believes BC drops back to standard time for winter, the same as it did in 2025 and every year before. It never got the memo.

To see the rule itself instead of one sample point, I dumped the transition table.

Read the bottom two lines as a pair. At 08:59:59 UTC, the clock is in PDT, offset -25200 seconds, UTC-7. One second later, at 09:00:00 UTC, it flips to PST, offset -28800, UTC-8, and the local time drops from 01:59:59 back to 01:00:00. That is the fall-back, drawn out in black and white, still scheduled for November 1. This is exactly the thing BC legislated out of existence, and this box has it right there on the calendar. Seeing it like that is what took me from “probably a problem” to “yes, definitely.”

The Bit That Nearly Caught Me Out

Before I patched anything, I ran one more check, and I am glad I did, because this is the part of the whole exercise most likely to burn someone. I asked what timezone the database resource itself starts up with.

Look at that. TZ=Canada/Pacific. My shell, my timedatectl, and every test I had just run were all on America/Vancouver. But the database does not start in my shell. Grid Infrastructure starts it and hands the instance Canada/Pacific. So all that careful testing had been pointed at a zone the database does not actually use. If I had patched, retested America/Vancouver, seen a clean result and closed the ticket, the instance could still have been wrong, and I would have walked away none the wiser.

Now, Canada/Pacific is an old alias that points to America/Vancouver underneath, so I fully expected the two to behave the same. But expecting is not checking, so I checked.

Same four lines, same fall-back. Good. Same broken rule, and it will take the same fix from the same package. The lesson I am keeping from this: on a Grid Infrastructure box, run srvctl getenv before you decide which zone to trust, because the instance’s idea of its timezone and your shell’s idea are not guaranteed to line up.

For the record, the listener getenv came back empty with no TZ line at all, which means it uses whatever the host is set to when it starts - nothing to do there.

The Fix Itself

One package update. That is the entire fix at this layer.

The repo had 2026c, which is a touch newer than 2026b where BC first landed. That is fine, better even. 2026c also carries a similar permanent-time change for Alberta, so if I ever point this at an Edmonton-zoned box, it is already covered. The rpm -q afterward confirms the box swapped 2023c for 2026c.

Checking My Work, on the Right Zone This Time

Now December comes back as 13:00, offset UTC-7, on both zone names. That is the permanent daylight time BC was after. The exact same instant that used to read 12:00 PST now reads 13:00, an hour later, because the box finally understands the clocks never fell back.

There is one thing here that will make you do a genuine double take, and it is worth slowing down on because it looks wrong and is not. The abbreviation says MST. Mountain Standard Time. The box did not move to Mountain. Ignore the letters and look at the offset: -0700 is UTC-7, which is the correct BC time. What is going on is a quirk in how tzdata labels a zone that is now permanently parked on what used to be its summer offset. Once the summer and winter flag stops flipping, tzdata reaches for the generic name for that offset, and the generic name for UTC-7 happens to be MST. The time is right; the label is just cosmetic and a bit strange. The only place this could ever bite you is if something in your stack keys off the letters “PDT” or “PST” rather than the offset. Worth a grep if you have that kind of tooling.

And the transition table again, to be thorough.

Compare that last line to the baseline. Before, it dropped to gmtoff=-28800, and the clock jumped back to 01:00. Now it stays at gmtoff=-25200, the clock rolls from 01:59:59 straight on to 02:00:00, and life carries on - no repeated hour, no lost hour. The November fall-back is simply gone, which was the entire goal.

Do Not Forget to Restart

Here is the mistake that is genuinely easy to make. The files on disk are fixed now, but the database and listener were started long before I ran that update, and a running process reads its timezone rules once at startup and then hangs onto them. So the instance is still carrying the old 2023c rules around in memory even though the disk is right. The only way it picks up the new rules is a restart.

The getenv after the restart still shows Canada/Pacific, which is correct and exactly what I wanted. I was never trying to change which zone the instance uses, only to refresh the rules sitting behind that zone, and the restart does precisely that.

Then I logged in and looked at the time.

This is where people get confused, so let me be blunt. It says -07:00 now, and it also said -07:00 before I started any of this. Nothing visibly moved. That is not a failure. It is September, and BC is on UTC-7 in September under both the old rules and the new ones, so today looks identical either way. The fix does not show up today. It shows up on November 1, when this box will now hold at UTC-7 instead of sliding back to UTC-8. I did the work in September on purpose, so that November turns out to be a complete non-event.

The Database’s Own Timezone File

One last thing I checked, because Oracle has a second, entirely separate timezone concept that constantly catches people out.

This is the database’s internal DST file, and it is a completely different animal from the OS package I just patched. It only matters for one specific data type, TIMESTAMP WITH TIME ZONE, and only when that data is stored against a named region. It has nothing to do with SYSDATE or SYSTIMESTAMP, and nothing to do with the November problem I just fixed. I am spelling this out because it is the single most common mix-up on this topic. People see an old version number here and panic, or they patch this file and think they have solved the clock problem. Neither is right.

The version here is 38, which is old. But the two lines beneath it are the ones I actually care about. DST_SECONDARY_TT_VERSION is 0, and DST_UPGRADE_STATE is NONE, and together they mean the database is sitting cleanly on a single version with no half-finished upgrade left hanging. That is a healthy, quiet state. I left it at 38 on purpose. If this database were storing future-dated Pacific timestamps in that particular data type, I would plan a separate upgrade to the version that carries the BC change (that is DSTv46, built from the same 2026c data). But that is its own job on its own schedule, and it changes nothing at all about November.

So What Actually Fixed November

Strip the whole thing down, and it is simple. The November problem was the operating system’s tzdata, full stop. SYSDATE and SYSTIMESTAMP come straight off the OS clock, so once the OS knows BC stays on UTC-7 and the database has been restarted to pick that up, the box is correct for November. The Oracle DST file is a side quest that only touches one data type. And the trap in the middle- the instance quietly running on Canada/Pacific while I sat there testing America/Vancouver- is the first thing I will check on every other box.

Demo is done. Start to finish, it was about ten minutes and one restart. The hardest part was mentally accepting that a clock showing the right time today can still be dead wrong about a date two months away.

Check out our Oracle Database Services here, or contact us today for more information and one of our experts will be in touch.