Recurring calls this autumn: whose clock moves, and on which date

A weekly 09:00 call set up from Vancouver will start at 08:00 for its Seattle participant on Tuesday 3 November. Nobody will have touched the invitation. British Columbia stops changing its clocks this year, Washington still falls back on 1 November, and the calendar keeps the call at 09:00 in the zone it was created in. [1] [2] [3]

Every standing call between places with different clock rules follows the same pattern this autumn. The event's own time zone holds still, and whoever sits outside it absorbs the difference. The dates below tell you when that happens; the tables tell you by how much. The people and calls in the examples are fictional, and the offsets come from the newest release of the time-zone database, 2026e.

The dates

[2] [4] [5] [3]

The US dates follow federal law: daylight time runs from 2 a.m. on the second Sunday of March to 2 a.m. on the first Sunday of November. [2] GOV.UK lists the UK changes for 25 October 2026 and 28 March 2027. [4] The EU and Sydney dates are as the tz database encodes them; we could not retrieve the EU directive text from EUR-Lex. [3]

The Canadian changes differ in name and offset. BC's new "Pacific time" is UTC−7, and the eastern BC communities that keep mountain time are outside it. [1] Alberta's year-round "Alberta Time" is UTC−6. [6] Manitoba announced on 17 September that clocks "will not revert to standard time on Nov. 1"; the tz database models Manitoba at UTC−5 from then on, and the Northwest Territories at UTC−6 alongside Alberta. [7] [5]

Whose clock moves

Calendar software stores a repeating event against one time zone. Google's developer documentation says so directly: "For recurring events, you must always specify a single time zone to expand the recurrences of the event." [8] Apple Calendar on the Mac shows and changes an event's zone once you turn on time-zone support under Calendar > Settings > Advanced; the macOS Tahoe 26 and macOS 27 guides give the same steps. [9] Outlook sends a meeting request with its UTC time plus the organizer's time zone and daylight-saving rules, and each attendee's Outlook works back to the organizer's intended local time before converting it. [10]

So the organizer's local time stays fixed, and everyone else's depends on the rules of two places. Here is a fictional Tuesday call at 09:00, anchored to Vancouver:

[3]

A participant in Calgary would see 10:00 all winter. The Winnipeg column never moves either, because Vancouver and Winnipeg both stop changing. London moves on the two European dates, Seattle and New York on the two American ones.

Now anchor the same group at 12:00 New York time. Vancouver then sees 09:00 until 27 October, 10:00 from 3 November and 09:00 again from 16 March. [3] Neither version is broken. The organizer's choice of zone decided who gets the earlier hour.

Pairs to check

Some wobble happens every year, because Europe falls back a week before the US and springs forward two weeks after it. Dates below are local dates where the clock changes; exact UTC boundaries are in the CSV.

[3]

The rows below are new this year. Seattle and Vancouver, Denver and Calgary, and Chicago and Winnipeg have shared a clock time all year until now; from 1 November they will differ by an hour each winter.

[3]

Transatlantic calls from western Canada change shape too. Vancouver is 7 hours behind London from 25 October right through to 28 March 2027, where it used to return to 8 hours on 1 November. Winnipeg is 5 hours behind London for the same stretch, instead of 6. [3]

Why two screens may disagree for a while

Every device and calendar service needs the new rules in its own copy of the time-zone data. The tz database, which many systems draw on, added the Canadian changes one release at a time: British Columbia in 2026b (22 April), Alberta in 2026c (8 July), the Northwest Territories in 2026d (11 September) and Manitoba in 2026e, released on 29 September, about a month before the date it matters. [5] [11] Companies then ship that data on their own schedules. An IT consultant quoted by CBC pointed out that calendar and booking companies often keep their own databases. [12]

The symptoms are already on record. CBC described a Calgary booking system that had moved every pre-booked appointment from November to March an hour later. [12] The University of Victoria warned staff that, for meetings from 1 November, a 10 a.m. Outlook meeting on one device "may appear as 11 a.m. on another." [13] Google's Calendar help notes that events in future years "might not reflect daylight saving time changes." [14]

Vendor status on 30 September:

• Microsoft has published interim guidance for British Columbia and for Alberta; the Alberta zone also covers Yellowknife and Inuvik. The update was scheduled for Windows 11 (24H2 to 26H2) in the September non-security preview of 22 September, and for other Windows versions in the 13 October monthly update. [15] [16] Its time-zone blog listed no Manitoba post when we checked. [17]
• Apple tells iPhone users that if a message says updated time-zone information is available, they should restart the device and any paired Apple Watch. [18] We found no dated Apple statement saying which Canadian changes it has shipped.

The Mac used for this analysis shows how the lag looks in practice. It runs macOS 26.3, and its time-zone data was version 2026c, which includes BC and Alberta. Asked for Winnipeg's offset on 15 November 2026, Apple's date framework answered UTC−6: it still expects Manitoba to fall back. On that Mac, a Chicago–Winnipeg call would look unchanged in November. Every other pair matched the 2026e results. [3]

To test a device or calendar service, create a throwaway event for Tuesday 3 November at 09:00 in the Canadian city's time zone, then view it in the neighbouring US zone; in Apple Calendar, the time-zone pop-up next to the search field switches the view. [9] A Vancouver event should show 08:00 in Seattle, a Calgary event 08:00 in Denver and a Winnipeg event 08:00 in Chicago. If it shows 09:00, that device or service doesn't have the new rule yet.

Five checks for each standing call

1. Find the event's time zone. In Apple Calendar, turn on time-zone support first. In Google Calendar, the zone sits next to the event time when you edit the event. [9] [14] An Outlook invitation carries the organizer's zone. [10]
2. Find the pair in the tables. If the gap changes, the person outside the event's zone is the one who moves.
3. Agree whose hour stays fixed and ask the organizer to set the series in that zone. For calls involving BC, UVic advises holding off on creating or changing non-essential recurring meetings that run past 1 November until vendor updates arrive, and putting the intended BC time in the subject line of important meetings; the same caution makes sense for Alberta, the Northwest Territories and Manitoba. [13]
4. Compare the first affected occurrence on two devices or services before it happens, after installing pending system updates. [15] If they disagree, don't change a device's time zone to force a match; UVic advises against it and suggests asking your IT support team. [13] Microsoft's temporary fixed-offset workaround is meant for organizations whose Windows devices can't install its update before 1 November. [15]
5. Send one line. For example: "From 3 Nov our Tuesday call is 08:00 your time, 09:00 mine. Same link."

If your calendar is connected to Kluro, it gives Kluro event details and attendees, which Preparation can use to bring back your shared history before the call. Kluro reads those events for context, and reading a source is not permission to change an external event, as the security page states; see the Calendar source page.

Method and limits

We downloaded tzdata 2026e from IANA, compiled it with zic and read UTC offsets with Python 3.11's zoneinfo every 15 minutes from 1 October 2026 to 30 April 2027 for 13 city pairs. Each city stands for an IANA zone (Seattle for America/Los_Angeles, Calgary for America/Edmonton). Rerunning with tzdata 2026d and with the Mac's own 2026c data gave identical results except for the three Winnipeg pairs, whose rule first appears in 2026e. [3]

The tz database temporarily models all four Canadian changes as happening at 02:00 on 1 November, although Manitoba's legally takes effect on 31 October. The clocks simply keep their current offset, so the times in these tables are the same either way. [5] The 2026e notes also say another release may be needed if parts of northwestern Ontario that usually follow Winnipeg do not follow this change. [5] The 2027 rows assume current law, including the US statute. [2]