Why DST Breaks Your Recurring Meetings and How to Fix It
DST breaks recurring meetings because the calendar can stay the same while the real overlap moves underneath it. The fix is operational review, not blind trust in the old invite.
Recurring meetings break around DST because cities switch on different dates or not at all. The invite may still exist, but the practical overlap has changed, which is why the meeting suddenly feels wrong.
Direct Answer
Most recurring meetings do not fail because the calendar software is broken. They fail because the team never re-checks the pair after the offset moves.
The Repair Process
- Identify the city pair that matters.
- Check whether the cities switched together, separately, or not at all.
- Confirm the live overlap again.
- Republish the slot in UTC and local city time.
The Common Failure Modes
| Failure mode | What it looks like | Fix |
|---|---|---|
| One side moved first | Someone is now an hour early | Reapprove the slot during the gap |
| One side never moves | The recurring band feels permanently worse | Reset the invite and document the pair |
| Nobody reviewed the window | Attendance drops quietly | Review before every transition season |
Where To Check The Pair
Frequently Asked Questions
Why does the invite still look correct when the meeting feels wrong?
Because the invite can remain intact while the real local times drift.
Should every recurring cross-region meeting be reviewed before DST season?
Yes. If the meeting matters enough to recur, it matters enough to review.
What should teams publish after the fix?
Publish the final slot in UTC and the local city times people actually follow.
Worked series: New York, London, Tokyo
This is the failure that recurring “Tuesday 9:00” invites hide. Under current civil rules — not a TimeNowHub measurement — the United States springs forward on the second Sunday in March and the EU/UK on the last Sunday in March. In 2026 that is 8 March in New York and 29 March in London: three weeks where a New York 09:00 / London 14:00 standup is really New York 09:00 / London 13:00. Tokyo does not observe DST (Asia/Tokyo), so its local clock never “helps” you during that gap.
Do not keep the old invite and hope. Load the three cities in the planner, generate the next 12 occurrences, and export an ICS only after the drift table shows a stable local time on every side.
Open the meeting planner with New York, London, and Tokyo preloaded
What the planner checks that this article cannot
- Private work hours and duration, not a public 09:00–17:00 assumption.
- Friday–Saturday weekends for Saudi Arabia, Qatar, Kuwait, and Oman when those cities are on the roster. Holiday projection is still labelled unavailable.
- Fairness across the series, not just the next Tuesday.
- A share hash and an ICS file — the artefact a snippet cannot copy.
Related pair pages to keep the local facts next to the tool: London ↔ New York and London ↔ Sydney (opposite-hemisphere DST).