A team in San Francisco runs a weekly Monday 9am call with their counterparts in London. For four months it lands at 5pm London — fine. Then daylight-saving ends in San Francisco on the first Sunday of November, but London held its clock change a week earlier. For one week, the meeting moves to 4pm London. Nobody noticed the calendar invite update; half the team showed up an hour late.
Every team with cross-time-zone meetings hits some version of this. It's not a calendar bug — it's a feature. Calendar apps store the meeting in the organizer's time zone, then convert to each attendee's local clock at display time. When DST shifts in one city but not the other, the gap between them changes by an hour. The attendee's local time moves; the calendar isn't lying, it's just doing what you asked.
Why DST changes the gap
Different countries observe daylight-saving on different dates, or not at all. The US shifts on the second Sunday of March and first Sunday of November. The EU and UK shift on the last Sundays of March and October — about a week apart from the US. India, Japan, China, and most of Africa don't observe DST at all. The gap between any two cities that don't shift together changes for that intervening week, and sometimes permanently.
A concrete example: SF Mondays at 9am Pacific across the next 12 weeks lands at these London local times:
| Week of | SF (PT) | London (GMT/BST) |
|---|---|---|
| Mar 9 | 09:00 PST | 17:00 GMT |
| Mar 16 | 09:00 PDT | 16:00 GMT (US sprang forward; UK hasn't yet) |
| Mar 23 | 09:00 PDT | 16:00 GMT |
| Mar 30 | 09:00 PDT | 17:00 BST (UK sprang forward; back in sync) |
| Apr 6 onward | 09:00 PDT | 17:00 BST |
For two weeks in March, this meeting lands at 4pm London instead of 5pm. If you set a recurring invite and promised "5pm London, every Monday," that promise is wrong for those two weeks.
The two patterns that cause most drift
- One side observes DST, the other doesn't. US ↔ India is the canonical example. The gap shifts by a full hour twice a year — for the whole DST season, not just the intervening week.
- Both sides observe DST but on different dates. US ↔ EU/UK. The gap shifts by an hour for ~1–3 weeks in March, then again in October/November. Easy to miss because it looks "in sync" most of the year.
How to see the cliff before it hits
The recurring meeting analyzer is built for exactly this question. Plug in:
- Source city (where the time is anchored — usually the organizer's city)
- Day of the week (Mon/Tue/Wed…)
- Time in the source city
- The other cities your meeting touches
- How many weeks to look ahead (default 12; up to 52)
The result is a table: one row per week, one column per city, showing local time in each. Any cell with a clock shift since the previous week gets a small DST pill, so the cliffs visually pop out before you hit them. With 4–10 weeks of lead time, you can warn your team and re-anchor the meeting if needed.
Practical tip: if you organize a recurring meeting that touches a city observing DST, run the analyzer once in February and once in September. Those are the two months when the next cliff is close enough to plan around but not so close that the meeting moves before you've sent a heads-up.
Three ways to handle a known cliff
- Accept the drift. If the affected weeks aren't critical (e.g. team is small, content is recoverable async), just notify the attendees that the time will shift for N weeks. Calendar invites handle the conversion; the only thing missing is the heads-up.
- Re-anchor temporarily. Move the recurring time by an hour for the intervening weeks so the non-shifted side stays at their usual local time. Annoying for the organizer but kind to the rest.
- Anchor in UTC instead. If your meeting is fundamentally global (e.g. four-region all-hands), consider anchoring in UTC and accepting that two cities' local time will shift every six months. It's the smallest combined-pain option for true multi-region meetings.
Why your calendar app won't do this for you
Google Calendar, Outlook, Apple Calendar — they all handle DST conversion correctly at display time, but none of them flag when an upcoming occurrence will be at a meaningfully different local time than recent ones. They show the upcoming time accurately; they don't say "by the way, this is an hour earlier than the last ten weeks, did you mean to do that?" That's the gap the recurring analyzer fills.
Related reading
- Daylight Saving Time and meeting planning — the broader DST primer.
- Time zone abbreviations are ambiguous — why "EST" and "CT" can mean different things.
- Calendar tools compared — how Google / Outlook / Apple Calendar handle (and don't handle) DST.