Alberta Stopped Changing Its Clocks. Your Control System May Not Get the Memo

Oct 7

6 min read

At 2:00 a.m. on Sunday, November 1, nothing is supposed to happen in Alberta. For the first time in decades, the clocks stay put. HOORAY! The province is now on permanent Alberta Time, UTC-6 all year, and the spring-forward back in March was the last clock change Albertans should ever see.

Your phone already knows this. Your laptop probably will by then. The Windows box running your HMI in a pumphouse outside Grande Prairie? It will dutifully roll back to 1:00 a.m. like it has every November since it was commissioned, and it will keep being an hour wrong until somebody fixes it.

That is the problem in a sentence. The rest of this post is about why it happens and what we're doing about it.

What actually changed

The Government of Alberta passed Bill 31, the Red Tape Reduction Statutes Amendment Act, 2026, which received Royal Assent in May and was proclaimed into force in June. The effect is simple: Alberta no longer falls back to Mountain Standard Time. The province stays at UTC-6 year-round, the offset we used to call Mountain Daylight Time. The government is calling it Alberta Time (ABT). The Northwest Territories announced it would follow Alberta, and British Columbia is doing the same thing on the same date at UTC-7.

Software vendors have been catching up through the summer. The IANA time zone database, which is what Linux, Java, Python, phones, and most embedded gear use, shipped the change in July as release 2026c. The America/Edmonton zone still exists, it just stops observing DST after November 1.

Microsoft took a different approach. Rather than change the existing Mountain Time zone (which also covers Denver, which is still changing its clocks), Windows gets a brand-new zone: (UTC-06:00) Mountain Time (Alberta), registry ID `Alberta Standard Time`. It shipped in the September 2026 optional preview update for current Windows 11 builds and lands for everything else, including Windows Server, in the October 13, 2026 security update. Microsoft's guidance is blunt: install it before November 1.

Why "install it before November 1" doesn't work in OT

On the corporate side, this is a non-event. Patch Tuesday comes, the update goes out, the fleet is done by the weekend.

At the plant floor, operational technology does not work that way, and for good reasons. The Windows machines in a plant are HMIs, SCADA servers, historians, engineering workstations, and the odd forgotten box running a vendor's licensing service. They sit on isolated networks with no direct path to Windows Update. Patches get staged, tested against the vendor's compatibility matrix, scheduled into a maintenance window that operations has to approve, and applied one area at a time with a rollback plan. A reboot on a SCADA server is a planned event, not a Tuesday afternoon.

Done properly, that cycle takes months. Across the sites we support, a Windows update released in October realistically reaches the last HMI somewhere between April and June of next year. Six to eight months is normal. It is not negligence. It is what careful looks like.

So we have a patch released two and a half weeks before the deadline, and a patching process that measures in quarters. The gap is wide and real.

Timeline from September 2026 to June 2027: Windows update released October 13, Alberta stops falling back November 1, a long bar for the typical OT patch cycle running into spring, and a short bracket in October labelled "interim fix" bridging the gap

What goes wrong if you do nothing

The computer thinks it is still on the old rules. On November 1 at 2:00 a.m. it sets itself back to 1:00 a.m. Every alarm, every event, every historian sample after that moment is stamped an hour early in local time, and the display clock on every screen in the control room is wrong.

A few knock-on effects we care about:

Your production data might be wrong. If your systems roll back and then we have to set them forward again you will see data quality issues in your daily production data around Nov 1. This includes a long day, a super short day, and bad volumes.
Operators lose trust in the timestamps. When the HMI says 06:00 and the wall clock says 07:00, every event log becomes a mental-math exercise during an upset. That's exactly when you don't want it.
Scheduled actions drift. Daily reports, shift-change logic, scheduled setpoint changes, and backup jobs that key off local time all fire an hour early.
Mixed fleets diverge. A patched engineering workstation and an unpatched HMI on the same network will disagree with each other by an hour for months. Correlating anything across them gets painful.
Regulatory and billing timestamps get messy. Custody transfer, emissions reporting, and anything an auditor might later ask about.

Note what doesn't go wrong: NTP. Time sync distributes UTC. Your clocks are not actually drifting, they are being displayed wrong because the local-offset rule is stale. That distinction matters because it means the fix is a configuration change, not a time correction.

Our interim approach: borrow Saskatchewan's clock

Here's the trick, and Microsoft recommends it as the official interim workaround in their Alberta guidance: Saskatchewan has been on UTC-6 year-round for decades. Windows has always had a zone for it, (UTC-06:00) Saskatchewan, registry ID `Canada Central Standard Time`. It has no DST rules. It is, for all practical purposes, Alberta Time with an older name.

So on every Windows machine we can't patch in time, we are doing one of two things:

Switch the time zone to (UTC-06:00) Saskatchewan. One command, no reboot, no patch:

   tzutil /s "Canada Central Standard Time"

Right now, in October, Alberta and Saskatchewan are both at UTC-6, so the displayed time doesn't move. On November 1, the machine simply doesn't fall back. That is the whole point.

Where the system is picky about zone names, pin it to a fixed UTC-6 offset. Some SCADA and historian products key behaviour off the Windows zone ID, or a vendor's compatibility documentation names a specific zone. Setting the machine to the plain `(UTC-06:00) Central America` zone or disabling automatic DST adjustment on the existing Mountain zone achieves the same result. Test it on the engineering workstation first.

Either way, this is a change you can make today, during normal hours, without a maintenance window, and verify immediately by checking that the clock didn't jump.

Three machines side by side: unpatched on Mountain Time showing 06:00 in red, interim on Saskatchewan showing 07:00 in green, patched on Mountain Time (Alberta) showing 07:00 in green. Caption: same offset, same time, only the first one is wrong

The catches

Nothing in OT is free. Three things to watch:

Labels will lie a little. A machine set to Saskatchewan will display "CST" or "Central" on some screens. The *time* is right. Tell your operators so nobody "fixes" it.
Mixed-zone fleets are fine, as long as the offset matches. A patched machine on Mountain Time (Alberta) and an interim machine on Saskatchewan agree on the time to the second. Just don't leave an unpatched machine on the old Mountain zone next to either of them.
Don't forget the non-Windows gear. PLCs, RTUs, protection relays, network switches, cameras, and Linux-based HMIs have their own DST rules in firmware. Many of them will fall back too. Where the device supports it, set it to UTC and let the SCADA host do the local conversion. Where it doesn't, it needs its own entry on the list.

When the October update finally works its way through your patch cycle, switch each machine to the proper Mountain Time (Alberta) zone during that same maintenance window. Treat Saskatchewan as the bridge, not the destination. The zone ID is what future Microsoft updates will key off, and the labels will finally say the right thing.

The real lesson

This isn't really a story about time zones. It's a story about the gap between how fast the world changes a rule and how fast a well-run control system can safely absorb it. Microsoft gave everyone eighteen days. OT needs six months. The job is knowing where that gap exists, finding the configuration-only fix that bridges it, and keeping an honest list of every box, Windows or not, that still needs the permanent one.

If you run industrial systems in Alberta, BC, or the Northwest Territories and haven't started that list yet, start it this week. November 1 is a Sunday. We'd rather you spend it sleeping.

Solving operational challenges in ways others have only imagined.