1-hour timezone gap broke Canada's Microsoft calendars

A 9 a.m. meeting in Vancouver now lands at 8 a.m. in Los Angeles — a 1-hour gap that did not exist on October 31. Microsoft's own guidance, updated November 2, names 8 products in its summary and 10 in its detailed table — and tells Manitoba Power Automate users to pretend they are in Bogota.

On November 1, 2026, British Columbia, Alberta, and Manitoba stopped turning their clocks back. BC stays on UTC-07:00, Alberta on UTC-06:00, Manitoba on UTC-05:00, all year. The United States did fall back on the same Sunday. That is the whole bug, and it is not a subtle one: it is a one-hour, continent-wide offset change that every calendar, scheduler, and cron-adjacent system had to absorb at once.

I measured it with Python's zoneinfo, on this machine, rather than trusting the press coverage:

from zoneinfo import ZoneInfo from datetime import datetime for zone in ["America/Vancouver", "America/Edmonton", "America/Winnipeg", "America/Los_Angeles", "America/Chicago"]: for day in ["2026-10-31", "2026-11-02"]: dt = datetime.fromisoformat(day + " 12:00").replace(tzinfo=ZoneInfo(zone)) print(zone, day, dt.utcoffset()) 

America/Vancouver 2026-10-31 12:00 UTC-07:00 America/Vancouver 2026-11-02 12:00 UTC-07:00 <- did not fall back America/Edmonton 2026-10-31 12:00 UTC-06:00 America/Edmonton 2026-11-02 12:00 UTC-06:00 <- did not fall back America/Winnipeg 2026-10-31 12:00 UTC-05:00 America/Winnipeg 2026-11-02 12:00 UTC-05:00 <- did not fall back America/Los_Angeles 2026-10-31 12:00 UTC-07:00 America/Los_Angeles 2026-11-02 12:00 UTC-08:00 <- fell back, as usual America/Chicago 2026-10-31 12:00 UTC-05:00 America/Chicago 2026-11-02 12:00 UTC-06:00 <- fell back, as usual 

The meeting arithmetic follows directly. A 9 a.m. Vancouver meeting was 9 a.m. in Los Angeles on October 31; on November 2 it is 8 a.m. in Los Angeles. A 9 a.m. Winnipeg meeting was 9 a.m. in Chicago on October 31; on November 2 it is 8 a.m. in Chicago. Same wall-clock time, same cities, one hour apart — because one side of the border changed the rules and the other did not.

The irony is that the open timezone database already knows this. My machine's zoneinfo returns the new offsets correctly. The lag is not in the data; it is in the enterprise stack built on top of it.

What Microsoft actually says

Microsoft published its guidance on October 26 — six days before the change — and was still adding products to it on November 2, the day after. I read the November 2 version (KB 5134344). Its "at a glance" summary names 8 products; its detailed table lists 10 rows, because Teams Events and Azure Automation were added in the November 2 update and Power Pages was already there:

Confirmed impact, detailed table (Microsoft, updated Nov 2, 2026): Outlook and Exchange Online (calendar) Microsoft Teams Rooms on Windows Teams Auto Attendant Teams Events SharePoint On-Prem Power Automate Desktop + Cloud Flows Azure Automation Dynamics 365 Finance and Operations Fabric Power Pages 

I am counting the detailed table, not the summary — the summary is already stale relative to its own page. That is the kind of discrepancy you should expect from a live incident document, and it is why I am quoting the date of the version I read.

The fixes are staggered, and none of them is "just install the update":

• Outlook and Exchange Online: changing your time zone does not migrate existing events. Organizers must update upcoming meetings themselves. A PowerShell cmdlet to remediate non-recurring meetings is targeted for November 4. Recurring-meeting remediation is "in development," with no ETA.
• SharePoint On-Prem: the correct time zones arrive November 10.
• Power Pages: server-formatted dates can appear one hour off until a service fix lands, with a December 12 milestone.
• Teams Rooms on Windows: affected devices displayed a time one hour behind Windows; the mitigation is updating Edge/WebView2 and verifying the room display.
• Fabric: the new zones are not available yet; use the stand-in zones below, ETA to be confirmed.

The workaround table is the story

For Power Automate, Azure Automation, and Fabric, Microsoft's temporary fix is to pretend you are somewhere else entirely:

Temporary mappings (Microsoft guidance, Nov 2): British Columbia -> Yukon Standard Time (Arizona for recurrence/schedule triggers) Alberta -> Canada Central Standard Time (Saskatchewan) Manitoba -> SA Pacific Standard Time (Bogota) 

Manitoba to Bogota is the one that travels, and it is not a joke — Bogota is UTC-05:00 year-round, which is exactly what Manitoba now is. The mapping is correct and also an indictment: a government changed its clocks, and the world's largest productivity vendor's answer, days after the change, is "tell the software you live in Colombia."

There is a real lesson here for anyone who builds scheduling software. Time zones are not geography; they are legislation with a database attached. The IANA database handled this change — my zoneinfo probe proves it — but every layer above it (product-specific time zone tables, cached meeting series, recurrence engines, room displays) has its own copy of the rules, its own release train, and its own idea of when "now" is. A calendar entry is not a timestamp; it is a timestamp plus a rule, and when the rule changes, the entry does not rewrite itself.

If you run anything that schedules across the US-Canada border, do the boring audit this week: list every meeting series created before November 1 that recurs after it, check the organizer (only the organizer can move a meeting), and verify the offset by hand against the table above. The one-hour error is silent — nothing crashes, nobody gets an error message, everyone just shows up an hour late or an hour early, and the meeting notes will say "great discussion" anyway.

Sources: Microsoft Support, "Canada 2026 time zone changes: Guidance for Microsoft products" (KB 5134344, originally published October 26, 2026, last updated November 2, 2026) — https://support.microsoft.com/en-us/servicing/os/windows/docs/2026/10/canada-2026-time-zone-changes ; The Register, "Microsoft's Canada timezone troubles leave admins fixing calendars, pretending they're in Bogota" (November 2, 2026) — https://www.theregister.com/software/2026/11/02/microsofts-canada-timezone-troubles-leave-admins-fixing-calendars-pretending-theyre-in-bogota/5306934 . All offsets above are from my own zoneinfo run on November 3, 2026.