# Why your recurring meeting drifts an hour twice a year *August 13, 2026 · Charles Brun · Playbook · Everest Blog* > A standing call that was fine in February is an hour wrong in March. Here is the mechanism behind it, why the clocks stopped agreeing, and how to pin a series so it holds. The weekly call has been at 3 p.m. since it was created. This week half the participants joined at what they thought was 3 p.m. and found the room empty, or full, an hour out. Nobody moved it. What moved was a clock, in one country, on a date the other country had not reached yet. ## An event is a wall-clock time plus a rule When you create an event, your calendar does not really store "3 p.m." It stores an instant, plus the zone that instant was expressed in. For a one-off meeting this distinction never surfaces. For a repeating series it decides everything. The series is expanded into future instances using the daylight-saving rules of the zone attached to it — so a call anchored to New York keeps following New York's clock, and moves relative to everyone else when New York changes and they have not. The bug is almost never a conversion mistake at the moment of booking. It is a series that was anchored to the wrong place, or to nowhere in particular, months earlier. ## The clocks stopped agreeing The comfortable assumption is that New York is five hours behind London and that is that. It is true for most of the year and false for about a month of it.
A timeline of 2026 showing the offset between New York and London, and between New York and Sydney. The New York to London gap is the usual five hours for 337 days but four hours for 21 days in March and 7 days at the end of October. The New York to Sydney gap takes four different values across the year, and the quoted sixteen hours holds for only 127 of 365 days.
Two city pairs across 2026, read from the tz database. The offset you quote is not the offset you get.
The United States springs forward on the second Sunday in March; the European Union waits until the last Sunday of the month. So for **21 days in March 2026** New York is four hours behind London rather than five. In autumn it reverses — the EU falls back first — for another **seven days**. Four weeks a year when a transatlantic invite is an hour away from what both sides assumed. Cross the equator and the tidy picture disappears entirely. New York to Sydney takes four different values during 2026, and the sixteen hours everybody quotes holds for **127 days out of 365**. | Both ends | What happens in 2026 | | --- | --- | | New York ↔ London | +5h, except 8–29 March and 25 October–1 November, when it is +4h | | New York ↔ Sydney | +16h, +15h, +14h, +15h, +16h — four changes in a year | If your standing meeting is anchored to one of these places and read from the other, those are the weeks it is wrong. ## What actually breaks - **Recurring series.** The most common and the most expensive, because nobody re-checks a meeting that has worked for six months. - **Series created in a hotel.** If you set up a recurring call while travelling, your calendar may have anchored it to wherever you were sitting. It will keep following that city forever. - **Events synced between providers.** A series that crosses a Google–Outlook sync can be expanded by two engines with different ideas about which zone it belongs to. The symptom is that only some attendees see the drift. - **All-day events.** These have no zone at all, which is correct for a birthday and wrong for a deadline. A day that begins at midnight somewhere begins on a different date somewhere else. ## The rules are political, and they keep changing It is tempting to treat this as a solved engineering problem. It is not, because the inputs are legislation. The European Union voted to end seasonal clock changes: Parliament adopted its first-reading position in **March 2019**. The file has been sitting with the Council ever since, unresolved, and Europe has changed its clocks every year in between. Any process that assumes the switch is about to be abolished has been wrong for seven years running. Meanwhile the map keeps moving. In 2026 alone, according to the maintainers of the [IANA time zone database](https://data.iana.org/time-zones/tzdb/NEWS): British Columbia stopped changing its clocks in March, Alberta moved to permanent standard time in June, and Morocco returns to permanent UTC in September. That database is the thing your calendar ultimately depends on, and it is updated irregularly — three releases in 2025, three so far in 2026 — whenever a government decides something. Updates reach you through your operating system, your browser and your calendar provider separately, which means they can each be working from a different version of the rules at the same time. > A detail that shows how rough the edges are: Alberta's move to permanent standard time legally > took effect on 18 June 2026, but the tz database deliberately models it as happening on 1 November > instead, as a temporary hack. The canonical source of truth knowingly disagrees with the law for > a few months, because that is the least bad option available. None of which is a reason for despair. It is a reason to anchor your meetings deliberately and check them twice a year, rather than assuming a solved problem. ## Fixing a series that has already drifted 1. Open the series, not a single instance — changes to one occurrence will not fix the rest. 2. Read the time zone shown next to the start time. That is the rule the series is following. 3. Set it to the city the meeting genuinely belongs to: where the customer is, where the team that cannot move sits, or wherever the majority actually are. 4. Save to the whole series, then check one instance either side of the next clock change before you trust it. If half your attendees are in another provider's calendar, ask one of them to confirm what they see after the change rather than assuming the update propagated. ## Four habits that prevent it - **Anchor every recurring meeting to a city.** Not to your laptop, and not to whatever zone you were in when you created it. If you need the mechanics, they are in [how to show multiple time zones in Google Calendar](/blog/google-calendar-multiple-time-zones/). - **Put the zone in the title where it matters.** `Ops sync (15:00 CET)` survives every clock change and every new joiner. - **Do not create standing meetings while travelling.** Or if you must, fix the anchor when you get home. - **Prefer a zone that does not change.** Where you have the choice — with a team spread across places that keep and drop daylight saving — anchoring to a non-observing zone removes the problem entirely rather than managing it. ## The twice-yearly check Put fifteen minutes in the calendar for the week after each transition. Two dates a year, and the list is short: 1. Open next week in your calendar with a second zone displayed. 2. Walk the recurring meetings that cross a border. Does each still sit inside working hours at both ends? 3. Fix the anchor on any that moved, at the series level. 4. Ask one person at the other end to confirm what they see. This is the cheapest maintenance in scheduling, and it prevents the most annoying class of failure — the meeting that is wrong for three weeks before anyone says anything, because each person assumed they had misread their own calendar. If the deeper question is not "why did this move" but "which hour should this have been in the first place", that is the subject of [how to schedule meetings across time zones](/blog/schedule-meetings-across-time-zones/). --- Published at https://everest.ag/blog/recurring-meeting-daylight-saving-drift/ · Everest is an AI scheduling assistant — CC it on any email thread and it books the meeting across every calendar you run. Learn more at https://everest.ag/