Daylight Saving and Recurring Meetings
By Mark Fulton · 2026-09-08 · 9 min read
A recurring meeting that spans two countries does not move on the same day for both sides. The United States changes its clocks on the second Sunday of March and the first Sunday of November; the United Kingdom and the European Union change on the last Sunday of March and the last Sunday of October; Australia changes on the first Sunday of October and the first Sunday of April. Because those dates don't line up, a call anchored to "9am my time" silently shifts by an hour for the other side for two to three weeks every spring and again every autumn, until both sides have finished switching.
Everyone can find the date their own country changes clocks. What's harder to find is what that date does to a meeting that already has a time zone attached to it, sitting on a calendar for the rest of the year. That's the actual problem, and it only shows up twice a year, for a few weeks at a stretch, which is exactly long enough to catch someone off guard and not long enough for anyone to remember it next time.
When do the clocks change in 2026?
These dates come straight from timeanddate.com's time change pages and cross-checked against Wikipedia's daylight saving time record, fetched today rather than carried over from a prior year. Rules repeat annually even when a specific date doesn't, so where a country's rule is fixed ("last Sunday in October") that's the more durable thing to remember.
| Region | 2026 clocks change | Rule |
|---|---|---|
| United States (most states) | Forward Sun, Mar 8 · Back Sun, Nov 1 | Second Sunday in March, first Sunday in November |
| United Kingdom & European Union | Forward Sun, Mar 29 · Back Sun, Oct 25 | Last Sunday in March, last Sunday in October |
| Australia (NSW, VIC, SA, TAS, ACT) | Forward Sun, Oct 4, 2026 · Back Sun, Apr 5, 2026 (season already ended; next ends Apr 2027) | First Sunday in October, first Sunday in April |
| India, most of Asia, Arizona (US), Queensland & Western Australia | No change, all year | Standard time year-round |
Danger window 1, Sun, Mar 8 to Sun, Mar 29, 2026: the US is already on daylight time; the UK and EU are still on standard time. Any US-UK or US-EU meeting is one hour off from its usual gap for three weeks.
Danger window 2, Sun, Oct 4 to Sun, Nov 1, 2026: Australia moves onto daylight time first, the UK and EU fall back to standard time three weeks later on Oct 25, and the US doesn't fall back until a week after that. A meeting that includes Sydney, London and New York passes through three different alignments inside four weeks.
Why does a recurring meeting move for only some people?
A recurring meeting invite stores one of two things: a specific clock time in a specific time zone, or a UTC instant. Almost every calendar tool (Outlook, Google Calendar, Zoom) stores the former, because that's what a person actually asked for: "every Tuesday at 9am my time." The calendar's job is to work out what 9am in your zone corresponds to in UTC for each occurrence, and it does that correctly, using the same tz database logic covered in how time zones and DST actually work.
The catch is that "9am my time" is only ever a promise about your own clock. It says nothing about anyone else's. If a colleague in London has the same meeting showing as 2pm on their calendar, that 2pm was calculated once, using the offset between your zones on the day the meeting was created. When one side's clocks move and the other side's don't, that offset is wrong until the second side catches up. Nobody's calendar is broken. Both calendars are doing exactly what they were told: hold your local time fixed, recompute the other zone's display time. The recompute only happens automatically for the zone that owns the invite; the guest's zone is a courtesy conversion that goes stale until their own DST rule fires.
This is worse for a recurring series than a one-off meeting because nobody re-checks a standing weekly call. A single scheduled interview gets a final "does 3pm still work" message. A Tuesday standup that's been running for two years does not.
Which regions don't change at all?
Roughly a third of the world's population lives somewhere that has never adopted daylight saving, or dropped it decades ago. India runs on Indian Standard Time year-round and has since independence. China standardized on a single time zone with no seasonal change. Japan, South Korea, and most of Southeast Asia never adopted it. Within countries that otherwise observe it, there are carve-outs: Arizona (outside the Navajo Nation) has opted out of US DST since 1968, and Queensland and Western Australia sit outside Australia's DST-observing states.
For a team split between a DST-observing region and one of these, the practical result is simpler than it looks: your meeting only ever needs adjusting on one side. If a call runs between San Francisco and Bengaluru, only the San Francisco time changes each spring and autumn; India Standard Time is the fixed point. That's a genuine advantage over a US-UK or US-EU call, where both sides move, just not on the same day.
What are the two mismatch windows each year?
There are two recurring windows, and they're not symmetric.
The spring window is the longer one. The US moves its clocks forward roughly three weeks before the UK and EU do (Mar 8 vs Mar 29 in 2026). For those three weeks, US Eastern time sits four hours from UK time instead of the usual five, and similarly one hour closer than usual to every EU zone. A meeting that reads correctly on both calendars in February will be an hour off in the first half of March.
The autumn window is where three regions overlap instead of two. Australia moves onto daylight time first (Oct 4 in 2026), while the UK and EU are still on their own daylight time until Oct 25, and the US stays on daylight time a further week after that, until Nov 1. A three-city call across Sydney, London and New York is never all "settled" for that whole four-week stretch: each leg of the triangle is on a different footing depending on which two of the three changes have already happened.
Both windows end the same way: once every region involved has finished its own transition, the gap between zones returns to its normal figure and stays there for months. The risk is concentrated entirely in the transition period, not the new steady state.
How should you anchor a recurring invite?
Pick the participant with the least flexibility, not the organizer, and set the recurring time in their local zone. If a client in London can't move a call and everyone else can, the invite should read "10am London time" in the calendar, and every other attendee's calendar should be left to do the conversion. This sounds like it shouldn't matter, since a calendar computes the same instant either way, but it matters in exactly the failure case above: whichever zone the meeting is anchored to auto-corrects the instant on its own transition date, and every other zone is a converted display that's only as fresh as the last time someone looked at it.
A second habit that costs nothing: when you set up a standing meeting that will run through a March or an October, write the anchor zone into the meeting title or description ("Weekly sync, 10:00 London, rotates for other zones"). It's a small thing, but it turns "wait, is this the old time or the new time" into a five-second lookup instead of a guess.
If the meeting needs to be genuinely fair over a full year, rotate the anchor zone deliberately on a schedule, rather than defaulting to whichever zone happened to create the invite. That's a separate problem from DST drift, but the two compound: a badly rotated meeting is also the one most likely to have nobody double-checking it across a transition.
What should you check the week before a change?
Three things, in order. First, check whether the region you didn't change with has changed yet, using the table above rather than memory. Second, open the actual meeting and read what time it currently shows for each participant, not what you assume it shows; if a calendar app displays a stale converted time because of a sync delay, this is where you catch it. Third, if the meeting is genuinely important, send a one-line confirmation to the other side ("still 3pm your time on Thursday?") for the first occurrence after either region's transition. A live check of both clocks side by side, like on a world clock showing every city involved at once, settles it faster than working through the arithmetic by hand.
Teams that run meetings across the US and India specifically can skip most of this twice a year, since only one side of that pairing ever moves; the full breakdown of which US zone lines up with which India time, in both directions, is in the US-India meeting time guide.
Frequently asked questions
Does daylight saving affect calendar invites?
Yes, but not the way people expect. The invite itself doesn't change; the underlying clock time each participant's calendar displays does, because that display is a conversion based on the offset between zones on the day the meeting was created. When one zone's DST rule fires and the other's hasn't yet, the conversion becomes stale until the second zone catches up, which can leave a guest's calendar showing the wrong local time for one to three weeks.
Which countries don't observe daylight saving?
India, China, Japan, South Korea, and most of Southeast Asia observe standard time year-round with no seasonal clock change. Within countries that otherwise use DST, there are exceptions: Arizona (outside the Navajo Nation) and Hawaii in the US, and Queensland and Western Australia in Australia, stay on standard time all year while the rest of their country changes twice a year.
Why do the US and Europe change on different dates?
Each sets its own rule independently, and the rules were written decades apart for different reasons. The US rule (second Sunday in March, first Sunday in November) comes from the Energy Policy Act of 2005. The UK rule (last Sunday in March, last Sunday in October), which the full UK time change record confirms for 2026, predates that and has stayed fixed since. Neither side has synchronized its dates to the other, so the roughly three-week spring gap and roughly one-week autumn gap recur every year by design, not by accident.
How do I stop a recurring meeting drifting?
Anchor the meeting's stored time to whichever participant has the least flexibility to move it, name that anchor zone in the meeting title so it's visible at a glance, and check the actual displayed time for every participant during the two windows each year when regions are out of sync with each other. There's no calendar setting that removes the need for this; the underlying mismatch is between countries' laws, not between calendar tools.