What DST does to a recurring calendar invite
Nothing visible. The entry is identical, the attendees are identical, and it happens an hour earlier for half of them — which is why nobody ever finds the cause.
The short answer
If the invite stored a zone, it survives. If it stored an offset or plain text, it does not.
The failure is invisible: nothing about the entry changes, so it looks like the meeting moved on its own. What actually happened is that the offset underneath it changed for one region and not the other.
What the calendar stored
This is the whole thing. Four possibilities, two of which survive:
| Stored as | Survives a transition? |
|---|---|
| Instant in UTC | Yes |
| Local time plus a zone id | Yes — the rule is re-applied per occurrence |
| A fixed offset, "UTC−5" | No — frozen at one season |
| Text in the description, "3pm EST" | No — nothing converts it |
A properly created event carries a zone. The same time re-typed into the description does not — which is why the event and its own body so often disagree after a clock change, and why the body is usually the one that is wrong.
The three ways it goes wrong
One region changed and the other did not. The US switches on 2026-03-08; the EU waits until 2026-03-29. For those three weeks a transatlantic recurring meeting is an hour off. Nothing is buggy — the real gap genuinely is four hours instead of five.
One side never changes. India, Arizona, Queensland and most of Asia do not observe daylight saving at all. Their gap to observing countries moves twice a year, and from their perspective nothing happened.
The series was created in the wrong zone. A recurring event created while travelling, or by an assistant in another country, anchors to that zone. It then tracks that zone's transitions rather than yours, and diverges from your local time twice a year forever.
Creating one that survives
- Create it in a calendar app with a zone attached — not as text, not as a fixed offset.
- Anchor it to the zone that matters. For a team meeting, that is usually the zone of whoever must be present. State which one you picked.
- Put both local times in the title, so a drift is visible immediately rather
than after somebody misses it:
Weekly sync — 16:00 London / 11:00 New York
- Check it after each transition. Four dates a year: 2026-03-08, 2026-03-29, 2026-10-25, 2026-11-01.
The "all-day event" trap
All-day events usually have no zone at all — they are a date, not an instant. That is correct for birthdays in your own country and wrong for anything with a time-sensitive meaning across zones, because the date boundary itself differs by several hours.
If it matters when in the day it lands, it should be a timed event.
And for anything automated
Define it in UTC. Cron entries, scheduled reports, on-call rotations and batch jobs written in local time will either skip the missing spring hour or run twice in the repeated autumn one. See what happens at 2am.
Related: Every March our weekly call moves · The three weeks the US and Europe are out of step
Timezone: World Clock Widget
A world clock, converter and live day/night map for iPhone — 325 cities, offline, no account.
Figures on this page are computed from the IANA time zone database. Last generated 2026-08-18.