How Daylight Saving Time Quietly Breaks Recurring Meetings

Your weekly sync has met at the same time for two years. Then one Monday in March, half the team logs in an hour early and the other half an hour late. Nobody touched a setting. No invite was edited. Yet the meeting moved.

This is the quiet failure mode of recurring events. Daylight Saving Time doesn't corrupt your calendar so much as expose an assumption it was making all along: that a meeting is a time. It isn't. A recurring meeting is a *rule* anchored to one clock, and twice a year the world's clocks stop agreeing on what that clock means.

The maddening part is that every calendar involved is technically correct. Each attendee sees a time consistent with the rules their own region follows. The trouble is that those rules flip on different dates in different places, and when the meeting's anchor lives in a different country than you do, DST turns a fixed promise into a moving target.

A recurring event is anchored to one clock

When you create a recurring meeting, your calendar app does not store "9:00 a.m. for everyone." It stores a single anchor: one local time, in one time zone, plus a repetition rule. Every other attendee's displayed time is computed from that anchor at the moment they look.

Say the organizer is in New York and sets a call for 9:00 a.m. America/New_York, every Monday. The app treats "9:00 a.m. New York" as the source of truth and converts it for everyone else when their calendar renders. A colleague in London sees whatever 9:00 a.m. New York happens to equal *that week*.

Here's the catch. The gap between New York and London is not fixed. For most of the year it is 5 hours, with London ahead. But for a couple of windows in spring and autumn it narrows to 4 hours, because the two regions switch their clocks on different dates. The anchor never budged — 9:00 a.m. New York is still 9:00 a.m. New York — but the *converted* London time slides by an hour until both sides finish transitioning.

So the meeting only "breaks" for people who are not in the anchor zone. If you organized it from the anchor city, you notice nothing. If you're an ocean away, your 2:00 p.m. quietly becomes 1:00 p.m. for two weeks, and nothing in the invite explains why.

Floating time: the sharper version of the bug

There is a nastier variant. Some events are stored as floating time — a wall-clock time with *no* time zone attached. Many all-day events and certain imported `.ics` entries behave this way. A floating "10:00 a.m." means 10:00 a.m. wherever the viewer happens to be, and it never converts at all.

Drop a floating event into a cross-zone team and DST scrambles it in ways that are genuinely hard to diagnose, because there is no anchor to reason from — each person is effectively in their own universe. The fix is almost always to convert the event to a zoned time tied to a real IANA zone like `Europe/Berlin`, never a bare offset or a floating value.

Why offsets misalign: the transition calendar

DST headaches come from the gaps between transition dates, not the transitions themselves. Each region picks its own switch days, and they rarely coincide. The result is a handful of short windows each year when the usual offset between two cities is temporarily off by an hour.

The major rule sets work like this:

• United States and Canada: spring forward on the second Sunday in March, fall back on the first Sunday in November.
• European Union and United Kingdom: spring forward on the last Sunday in March, fall back on the last Sunday in October. (The change happens at 01:00 UTC across the bloc, so the entire region pivots at the same instant.)
• Australia (only ACT, NSW, SA, Tasmania, and Victoria): Southern Hemisphere, so the seasons invert — clocks fall back on the first Sunday in April and spring forward on the first Sunday in October. Queensland, Western Australia, and the Northern Territory don't observe DST at all.

Line those up and the misalignment windows fall out:

• Mid-to-late March: the US has already sprung forward (second Sunday), but the EU and UK haven't (last Sunday). For roughly two weeks, the New York–London gap shrinks from 5 hours to 4. Any meeting anchored in either zone drifts an hour for everyone in the other.
• Late October to early November: the EU and UK fall back first (last Sunday in October), then the US falls back a week later (first Sunday in November). A one-week window where the transatlantic gap is off by an hour.
• Early April and early October: because Australian DST runs opposite the Northern Hemisphere, the US-to-Sydney and UK-to-Sydney gaps swing by a *full two hours* across the year. The brief overlaps when one hemisphere has switched and the other hasn't are when Asia-Pacific calendars misfire worst.

A concrete walk-through. A London-anchored call at 3:00 p.m. Europe/London, with one attendee in New York:

• Normal weeks: 3:00 p.m. London = 10:00 a.m. New York (5-hour gap).
• The mid-March window: New York has sprung forward but London hasn't, so the gap is now 4 hours. The same 3:00 p.m. London anchor lands at 11:00 a.m. New York. From New York's side the meeting "moved" an hour later for two weeks, then snapped back the moment London sprang forward.

Multiply that across a global team and you get the familiar twice-a-year chaos: some pairs stay aligned, others drift, and which is which depends entirely on whose zone the event was anchored in.

Zones that never drift — and how to use them

Not everyone observes DST, and that's leverage. Large parts of the world hold a fixed offset year-round: most of Asia (India, China, Japan, Singapore), most of Africa, and within the US, Arizona (except the Navajo Nation, which does observe DST) and Hawaii.

The payoff: if your meeting is anchored in a non-DST zone, attendees *in other non-DST zones* never drift relative to it. Drift only ever appears across the boundary between a DST-observing region and a fixed one. A team split between Bengaluru (IST, no DST) and Berlin (CET, with DST) will see their gap change by an hour twice a year — and it will always be Berlin's transitions causing it, never Bengaluru's. Knowing which side moves tells you exactly who to warn.

How to keep recurring meetings stable

You can't stop governments from changing their clocks, but you can decide *which* hour stays fixed and *for whom*. The goal is to make the drift predictable and put it where it does the least harm.

1. Anchor to the zone that matters most

Decide whose local time must stay constant — usually the largest group, the paying client, or the person who physically cannot move (a school run, a caregiver, a fixed shift). Anchor the recurring event in that person's IANA zone. Everyone else absorbs the twice-a-year shift. This doesn't eliminate drift; it relocates it to whoever can handle it best.

2. Pick a named zone, never a raw offset

When the app asks for a time zone, choose a region like America/Chicago or Australia/Sydney — not "UTC-6" and not an abbreviation like CST, which is ambiguous (it can mean Central Standard Time in North America *or* China Standard Time *or* Cuba Standard Time). A named IANA zone carries the full DST rule set, so the app transitions automatically. A fixed offset can't transition — it will silently be wrong for half the year.

3. Mark the four danger Sundays

Put a standing reminder in your own calendar for the misalignment weeks:

• Second Sunday of March: US transitions; transatlantic gaps go off until the EU/UK catch up.
• Last Sunday of March: EU/UK transition; transatlantic gaps realign.
• Last Sunday of October: EU/UK transition; gaps go off until the US catches up.
• First Sunday of November: US transitions; gaps realign.

During these windows, double-check any externally facing recurring call — interviews, client demos, webinars. A one-hour drift in front of a customer costs far more than an internal slip.

4. Confirm the converted time; don't assume it

Before each window, run the anchored time through a converter that respects DST rules for a *specific date*. Timezio's meeting planner shows each attendee's actual local time on the exact day in question, so you can see at a glance whether next Monday's call still lands where you expect — instead of trusting a mental "minus five hours" that quietly breaks twice a year.

5. For truly global events, pin to UTC and re-announce

For a standing all-hands spanning many continents, some teams stop trying to hold any one local hour fixed and instead **pin the event to a UTC instant**, accepting that the local start shifts for everyone whenever their own clocks change. This trades "the same wall-clock time" for "the same absolute moment." It suits async-friendly cultures and events where being together at one true instant matters more than convenience. If you go this route, re-announce the local start times right after each transition so nobody is guessing.

A quick diagnostic checklist

When a recurring meeting suddenly drifts, walk through this in order:

• Who is the anchor? Identify the single zone the event is stored in. The person in that zone never sees drift; everyone else might.
• Named zone, or bare offset/abbreviation? Fixed offsets and ambiguous abbreviations are the single most common root cause.
• Is it floating (no zone at all)? All-day and imported events often are — convert them to a real IANA zone.
• What's the date? Cross-reference the four transition Sundays. If you're inside a misalignment window, the "bug" is expected and temporary.
• Did someone duplicate or re-import the series? A recreated recurring event can quietly reset the anchor to whoever rebuilt it, in their zone.

The lesson is simple once you see it. A recurring meeting is not a time — it's a rule, anchored to one clock, evaluated fresh every week. DST doesn't corrupt the rule; it reveals that the rule was always relative to a place, not a universal moment. Pick your anchor on purpose, name your zones precisely, and mark the four Sundays a year when the world's clocks briefly disagree. Do that, and the twice-yearly drift stops being a mystery and becomes something you can see coming.