The Clocks Stop on November 1

On the first of November, at two in the morning, Alberta's clocks will not fall back. They will stay where they are, and they will stay there: permanent daylight time, six hours behind universal time, all year. British Columbia did the same thing in March. Manitoba does it the day before Alberta. The Northwest Territories is following. For most people this is a story about sleep and school mornings, and there are good pieces about that. This is a story about software, because software is where the change will go wrong.

The rule that just changed

Every computer, phone and server in the world decides what time it is in Edmonton by looking up a rule: Edmonton is in the zone called America/Edmonton, and that zone's rules say when the offset changes. The rules live in a shared database that every operating system and programming language copies. The Alberta change was written into that database this year, in a release numbered 2026c; Manitoba's came in a later one. Your laptop has it if your laptop has been updated. The server running your booking system has it if someone updated that server. The small device in the phone closet that plays your after-hours message has it if, well.

Here is the part that bites. Until now, Edmonton and Denver kept the same time all year, and a great deal of software quietly relies on that: it stores “Mountain Time” rather than “Edmonton,” or it uses Denver as a stand-in because they were always equal. From November 1, Denver falls back and Edmonton does not. Every winter from now on, Edmonton is an hour ahead of Denver, and any system that treated them as the same will be an hour off for four months of the year, every year.

Four things to check before November 1

• Your calendar's zone. Open the settings and read the exact name. A zone named for Edmonton is fine. “Mountain Time (US & Canada)” is the one to worry about.
• Your booking system's clock. Ask the vendor one question: which time-zone rules does the system use, and has it been updated for Alberta's permanent time? A vendor who answers with a release number has done the work.
• Your phone system's schedule. After-hours greetings, call routing by time of day, and any reminder calls or texts that go out at a set hour all run on a clock. Find out whose.
• Staff devices. Phones and laptops that have not taken an update since the spring will fall back on their own and disagree with the wall clock on the morning of the first.

The question we ask at every start

I will say what we do, because I think it is the right shape for anyone running software a clinic depends on. Our platform does not take the time from the server it happens to be running on. It reads the zone rules from a package we pin by version and ship inside our own runtime, so an unpatched operating system underneath cannot make the clinic's clock wrong. Earlier this month we pinned the release that carries all of Canada's changes, and a test in our build fails if that pin ever slips below it.

And because a pinned package is still only a number, every one of our services answers one question when it starts, and writes the answer into its log: what is the time in an Alberta clinic at noon on the fifteenth of November? The same question is part of the readiness check a clinic's phone line has to pass before it goes live, because the assistant books appointments in the clinic's own time, and a booking an hour off is a booking in a patient's day that does not exist. If the answer is not six hours behind universal time, the check fails, and we do not put a line live on a failed check.

Most clinics will learn about the change from a vendor notice, buried in a mailbox, in a month when they are busy with something else. The difference between a line in a notice and a check that runs on its own is the whole difference between knowing something and being protected by it.

Three weeks. Check the four things. If you cannot get a straight answer on the second one, that is itself the answer.