Why Your Recurring Meeting Shows the Wrong Time Twice a Year
You set a weekly call. It runs fine for months. Then one week in spring or autumn half the participants arrive an hour early, or the organiser finds their own meeting has moved. This is not a bug in the calendar, and it is not anybody forgetting the clocks changed. It is a consequence of how the event stored its time in the first place.
Three ways to store a time, and they behave differently
Every calendar system can represent a time in three fundamentally different ways. Which one an event uses determines what happens to it at a daylight saving transition.
Floating time
Just a wall-clock time with no zone attached: 09:00, full stop. It means nine in the morning wherever the viewer happens to be. This is right for an alarm clock or a birthday and almost always wrong for a meeting, because two participants in different countries will see it as two different moments.
A fixed instant, usually stored as UTC
An exact point on the world's timeline, such as 09:00 UTC. It never moves in absolute terms. That sounds like the safe option and it is the source of most of the trouble, because while the instant stays fixed, the local time it corresponds to does not.
A zoned time
A wall-clock time plus the name of the zone that governs it: 09:00 in Europe/London. In the iCalendar format this is the TZID field. This is the only one that means "nine in the morning in London, whatever London's offset happens to be that week".
The classic failure
Here is the sequence that catches people out, and it catches the organiser rather than the attendees.
Someone in London sets a recurring meeting for 09:00 on a winter Monday. London is on GMT, so 09:00 local equals 09:00 UTC. If the system stores that as a fixed UTC instant rather than as a zoned time, everything looks correct.
In late March, London moves to British Summer Time at UTC+1. The stored instant has not changed, but 09:00 UTC is now 10:00 in London. The organiser's own weekly meeting has silently moved an hour later in their own working day, and nobody touched it.
The mirror image happens when an event is anchored to a zone that does not observe daylight saving while the participants are in zones that do. The absolute instant holds, the local times drift, and the meeting that was comfortably mid-afternoon for everyone becomes a lunch break for half of them.
Why recurrence makes it much worse
A recurrence rule does not store a list of dates. It stores a pattern, such as "every Monday", which the calendar expands into actual instants using the event's time zone.
That means the zone is not just metadata on the first occurrence. It governs every future occurrence. Get it wrong and you have not misplaced one meeting, you have misplaced an unbounded series of them, and the error only becomes visible months later when a transition crosses the series.
It also means you cannot pin future local times by converting them to UTC in advance. Daylight saving rules are not fixed facts about the future: they are current policy, and policy changes. When Mexico abolished daylight saving in 2022, every already-scheduled future meeting anchored to a Mexican zone moved, because the rule that had been used to calculate it no longer applied. A UTC instant stored in advance would have been frozen at a local time that no longer existed.
Why two tools disagree about the same event
The other common symptom is an event that reads differently in different applications. This usually comes from the handoff between them.
Calendars that store a proper zone keep the TZID. But plenty of integrations, export scripts and notification services flatten an event to a UTC instant on the way through, because an instant is simpler to pass around. Once that happens, the zone information is gone and cannot be recovered: the receiving system has a correct moment and no idea which wall clock it was supposed to track.
There is also a historical wrinkle. Some ecosystems maintained their own list of time zones rather than using the standard IANA one, with different names and sometimes different rules. Mapping between the two is imperfect, and the mismatches tend to surface exactly at transitions.
What to actually do
- Set the event's time zone explicitly. Most calendars let you choose a zone per event and default to your own. For a meeting that belongs to a particular office or market, set that zone rather than accepting the default.
- Decide which city the meeting belongs to. "09:00 in London" and "09:00 in New York" are both reasonable choices and they diverge for four weeks a year. Pick one deliberately and tell participants which it is.
- Never store a future recurring event as a bare UTC instant. Use UTC for recording things that already happened. Use a named zone for things scheduled to happen.
- Audit standing meetings in mid-March, late March, late October and early November. Those are the four windows when the US and Europe are out of step, and they are when a mis-stored event will reveal itself.
- State the local time for each side in the invitation body. Plain text in the description survives every conversion that strips metadata, and it gives attendees something to check against.
If you run a regular call across a specific pair of cities, the comparison pages show the live difference and the hours when both working days actually overlap, computed from the offsets in effect right now rather than from a remembered average. That is usually enough to catch a drifted meeting before anyone misses it.