When most of North America set its clocks back on November 1, 2026, large parts of western and central Canada stayed put. British Columbia, Alberta and Manitoba moved to permanent daylight time, locking in fixed offsets of UTC−07:00, UTC−06:00 and UTC−05:00, with affected parts of the Northwest Territories (including Yellowknife and Inuvik) following Alberta and Northwestern Ontario following Manitoba. Microsoft shipped new Windows time zones ahead of the change, but its own guidance (KB5134344, last updated November 2) lists confirmed impact across Outlook and Exchange Online, Teams Rooms on Windows, Teams Auto Attendant, Power Automate, Fabric, SharePoint Server, Bookings and Dynamics 365 Finance and Operations. The headline problem is simple: existing meetings don’t move to the new zones on their own, so anything booked in the old US-linked zones drifts by an hour. Microsoft’s new Invoke-CalendarEventMigration cmdlet handles part of the cleanup, but not recurring meetings yet. Here’s what broke, what the fix covers, and how to work through it if you support users in these provinces.
What Changed on November 1
Until this year, users in Vancouver, Calgary and Winnipeg simply used the shared US and Canada zones: Pacific, Mountain and Central. Those zones still fall back every autumn, so they no longer describe local time in the affected provinces. Windows and Outlook now offer three new zones, and every device, mailbox and calendar event that should follow the new rules has to be moved onto them.
- British Columbia: (UTC−07:00) Pacific Time (British Columbia), Windows ID British Columbia Standard Time
- Alberta: (UTC−06:00) Mountain Time (Alberta), Windows ID Alberta Standard Time
- Manitoba: (UTC−05:00) Manitoba, Windows ID Manitoba Standard Time
- Windows itself: Microsoft says the time zone updates have been released, but devices on unsupported Windows versions won’t receive them
Microsoft also warns admins not to pick mailboxes just because they currently sit in Pacific, Mountain or Central time, because those zones still serve plenty of users in places that didn’t change. Targeting has to come from where people actually work.
Outlook and Exchange Online Take the Biggest Hit
Calendars are where users feel this first. According to Microsoft Support, existing events and meetings do not migrate automatically, so a 9 AM meeting created in Pacific Time (US & Canada) shows up an hour off once the US zone falls back. Only the organizer can fix a meeting that has attendees, and changing the time zone on a recurring series resets every exception in that series, so moved or cancelled instances have to be recreated.
Microsoft’s Message Center post MC1521581 breaks the fix into three separate settings, and they don’t update each other:
- Mailbox time zone: what new Outlook and Outlook on the web use to show the calendar and create new events. Changing the Windows clock doesn’t touch it. Set it with Set-MailboxRegionalConfiguration, or have users change it under Settings, Calendar, View, Time zones
- Windows time zone: the equivalent setting for classic Outlook
- Existing calendar events: each event carries its own time zone and must be migrated, either by hand or with Invoke-CalendarEventMigration
- Working hours time zone: drives free/busy and availability. Set it with Set-MailboxCalendarConfiguration and the WorkingHoursTimeZone parameter
Microsoft also lists free/busy and Work Hours and Location in new Outlook and Outlook on the web as still under investigation, and IT admins cited by Windows Report are already complaining about wrong working hours and inconsistent time zone data across Windows, Linux and database systems.
The New Invoke-CalendarEventMigration Cmdlet
The main remediation tool is a new Exchange Online cmdlet. As Microsoft’s documentation puts it, the cmdlet “migrates meetings from one time zone to another while keeping the same local time,” so a 9 AM Pacific Standard Time meeting becomes a 9 AM British Columbia Standard Time meeting. Microsoft’s product guidance targets November 4 for the release, and the Message Center post says rollout to the worldwide cloud completes by November 2, so check your own tenant before you script around it. A typical run looks like this:
Invoke-CalendarEventMigration user1@contoso.com -FromWindowsTimeZoneId "Pacific Standard Time" -ToWindowsTimeZoneId "British Columbia Standard Time" -QueryStartDate 2026-11-01 -QueryWindowInDays 365 -PreviewOnly
Drop -PreviewOnly once the preview list looks right. The limits matter just as much as the syntax:
- One mailbox at a time: you loop through your list of affected users yourself
- Single-instance events only: recurring meetings aren’t supported in the first release. MC1521581 says support is expected mid-November, while Microsoft’s KB still lists the date as to be confirmed
- Organizer mailboxes only: meetings where the mailbox is just an attendee are skipped and must be fixed from the organizer’s side
- Default Calendar folder only: secondary calendars aren’t touched, and Group mailboxes aren’t supported yet
- Attendees get updates: every migrated meeting sends an update message, and those count against Exchange Online sending limits, so Microsoft suggests starting with a 7-day query window and widening it
- Safe to rerun: Microsoft says you can rerun it after a timeout or once recurring support arrives
Teams, Power Platform and the Rest of the Stack
Outlook isn’t the only thing running an hour off. Microsoft’s guidance lists a mix of fixes and stopgaps across the rest of Microsoft 365:
- Teams Rooms on Windows: room displays showed time an hour behind Windows. Update Microsoft Edge and WebView2, then check the display matches the system clock
- Teams Auto Attendant: the new zones may not be available yet, so update time zones manually per Microsoft’s guidance
- Teams Events: organizers can use stand-in zones with the same offset: Saskatchewan for Alberta, Yukon for British Columbia, and Eastern Time for Manitoba
- Power Automate and Azure Automation: flows using US-linked zones drift by an hour. Until the new IDs are supported, map Alberta to Canada Central Standard Time, British Columbia to Yukon Standard Time (Arizona for recurrence triggers) and Manitoba to SA Pacific Standard Time, and don’t use the new province IDs there yet
- Fabric and Power BI Service: the new zones aren’t available yet; use Arizona, Saskatchewan and Bogota/Lima/Quito as temporary choices
- SharePoint Server (on-premises): an update is due November 10
- Power Pages: server-formatted dates can be an hour off, with a service fix targeted for December 12
- Dynamics 365 Finance and Operations: install the customer hotfixes, then have users pick the new zone
Teams desktop, web and mobile clients, other Teams devices and Outlook for iOS, Android and Mac are still listed as under validation, so keep them current and spot-check meetings booked after November 1.
A Practical Cleanup Order for Admins and MSPs
If you look after tenants with staff in these provinces, a sensible order of operations based on Microsoft’s guidance looks like this:
- Build the user list: identify affected users by office location, not by their current time zone setting
- Patch Windows: confirm devices are on a supported, current build so the new zones exist, and fix the Windows time zone for classic Outlook users
- Set the mailbox and working hours zones: script Set-MailboxRegionalConfiguration and Set-MailboxCalendarConfiguration across the list
- Migrate one-off events: run Invoke-CalendarEventMigration in preview, then for real, in small date windows
- Triage recurring series: decide whether organizers fix key series by hand now (rebuilding exceptions) or wait for the updated cmdlet and rerun it
- Fix the rooms and flows: update Edge and WebView2 on Teams Rooms, and remap Power Automate, Azure Automation and Fabric schedules
- Escalate cleanly: Microsoft asks admins to put #CanadaTimeZone in the support case title so cases get routed quickly
Give users a heads-up before you migrate, too. A burst of meeting updates from colleagues with no explanation is exactly the kind of thing that generates tickets, and attendees outside Canada will see them as well.
Looking Ahead
The next milestone is the updated cmdlet with recurring meeting and Group mailbox support, which Microsoft has pointed to for mid-November. Until then, the safest approach is to migrate one-off events now, fix the handful of recurring series that really matter by hand, and plan a second pass once the new version lands. Keep an eye on KB5134344, which Microsoft has been updating every few days with new products and workarounds.
The bigger lesson is about lead time. Admins have criticized how late the Windows updates arrived before November 1, and changes like this touch far more than the system clock. Time zone data lives in mailboxes, events, workflows, room devices and line-of-business apps, and each layer needs its own fix. For anyone running Microsoft 365 for Canadian clients, this week is a good time to make sure every one of those layers agrees on what time it actually is.
Sources:
- Microsoft Support (KB5134344, Canada 2026 time zone changes: Guidance for Microsoft products), November 2, 2026
- Microsoft 365 Message Center (MC1521581), October 30, 2026
- Microsoft Source Canada, October 30, 2026
- Windows Report, November 2, 2026
