Schedule Recurring Meetings: Beat 21-Day DST Drift

A recurring meeting is a promise that repeats itself. Daylight saving time is the one thing that quietly breaks that promise twice a year — and not on the day your own clock moves, but during the awkward window when your clock has already changed and your colleague's has not. That window is what this article is about: how to find it, how long it lasts, and what to actually put in the calendar invite so nobody shows up an hour late.

What "mismatched daylight saving dates" really means

Most people assume the problem with DST and scheduling is the hour you lose in spring. It is a real annoyance, but it is not the scheduling problem. The scheduling problem is that the world does not change its clocks on the same day.

The European Union moves to summer time on the last Sunday of March. The United States moves on the second Sunday of March. Those two dates are almost never the same. For the days in between, one region is on daylight time and the other is still on standard time. The absolute gap between the two zones shrinks by exactly one hour — not permanently, but for a bounded window that most teams never plan for.

The same thing happens in reverse in autumn. The EU falls back on the last Sunday of October. The US falls back on the first Sunday of November. Again there is a gap where one side has already reverted and the other has not.

So "mismatched DST dates" is not a vague warning. It is a specific, datable, countable interval — and once you can name it, you can plan around it.

The two mismatch windows in 2026

For the most common pairing in global work — North America against Europe — the windows in 2026 look like this:

Two things are worth noticing here.

First, the spring window is three times longer than the autumn one. The famous "21-day drift" is a spring phenomenon. If you only ever prepare once a year, prepare in late February, not in October.

Second, the drift does not change the meeting's absolute instant. It changes the local hour at which that instant lands. A call that sat at 14:00 London in early March will sit at 13:00 London from 8 March to 29 March, then snap back to 14:00 on 29 March. Nothing about the underlying UTC time moved. Only the wall clock did.

How we verified the exact offsets

Do not trust a rule of thumb here — dates shift year to year, and a one-day error means sending your drift notice a day late. The numbers above come straight from the same engine the converter tool uses, which reads live zone data through the browser's own internationalisation library:

A short table to make the swing concrete:

Read the middle rows and the pattern is clear: the gap is 5 hours, then 4, then 5, then 4, then 5 again. Every 4-hour row is a drift window. Every 5-hour row is normal service.

If you want to check this for your own pair of cities, use the offset readout in the converter rather than a static table — zone rules change more often than people expect, and a country can abolish or restore DST with little notice.

Why your recurring calendar invite will not save you

There is a widespread belief that modern calendar apps "handle DST automatically", so a recurring invite is safe. That is half true, and the half that is false is the expensive half.

When you create a recurring meeting, the app has to decide what stays fixed. If the invite carries a real time zone identifier — for example, "Europe/London" rather than a floating local time — the app keeps the absolute instant fixed and recalculates the local hour for each occurrence. That is correct behavior, and it is exactly why the meeting appears to move. The app is not broken. It is honoring a UTC anchor you never explicitly chose.

So the automatic behavior solves one problem (the meeting never silently becomes a different absolute time) and creates another (the local hour drifts for anyone in a region with different transition dates). You cannot have both from a single invite. You have to pick, and the pick should be deliberate.

Freeze the instant, or float the local time

There are only two honest strategies, and they answer different questions.

Strategy one — freeze the instant. Anchor the series to a single time zone, ideally UTC, and accept that the local hour will move during drift windows. This is the right choice for meetings where the participants are the constant and the clock is noise: engineering standups, incident reviews, trading desks, anything where "same moment, same agenda" matters more than "same breakfast hour".

Strategy two — float the local time. Anchor the series to each participant's local clock and accept that the absolute instant will move. This is right for meetings where the human rhythm matters: a 1:1 that must stay at 09:00 for someone's school run, a therapy or coaching session, a rehearsal across a few households. The cost is that the meeting lands at a different UTC moment during drift windows, and someone always notices.

What you must not do is leave the choice implicit. The default behavior of every calendar app is strategy one, and most people who believe they chose strategy two have actually chosen strategy one without knowing it.

Audit a recurring series in five steps

1. List every recurring meeting that crosses at least one DST boundary — that is, any series with participants in two or more regions that observe daylight saving.
2. For each one, write down the anchor: which time zone does the invite actually carry? Open the event and look. "Floating" is not a time zone.
3. Mark the two drift windows for that specific pair of regions in the current year. For US and Europe in 2026 that is 8–29 March and 25 October–1 November.
4. For each window, convert one representative occurrence by hand and compare it to the normal local hour. A single hour of difference confirms the drift; note it down.
5. Decide, per meeting, whether the drift is acceptable or whether you will temporarily shift the series, and write that decision into the event description so the next organizer inherits it.

Five steps, once a year, in late February. That is the whole maintenance burden.

The drift notice you should send every year

The cheapest fix is communication, but only if the communication is specific. "Heads up, DST is coming" is noise. A notice that names the window, the direction, and the resolution is useful:

• The window, dated: "From 8 March to 29 March, our Thursday call moves one hour earlier in London and Europe."
• The reason, one line: "The US changes clocks three weeks before the EU."
• The resolution, explicit: "No action needed — the invite is anchored to New York, so London will see 13:00 instead of 14:00 for three weeks, then revert automatically."
• The escape hatch: "If that hour breaks your day, tell me and we will move the whole series for the three weeks."

Notice what the third line does. It tells people what they will see and why, so the change reads as expected behavior rather than a bug. Most DST confusion is not a calculation failure; it is a communication failure.

The trap the converter will not flag for you

Here is the part that makes this genuinely tricky, and it is worth understanding because it affects any tool, not just this one.

The converter decides whether a zone is currently on daylight time by comparing its offset today against its offset in mid-January of the same year. If the two differ, it labels the zone "DST on". That reasoning works perfectly for the Northern Hemisphere, where January is winter and the standard-time baseline is genuinely standard.

It inverts in the Southern Hemisphere. In Sydney, January is summer — the middle of daylight saving. So when you ask the tool about a January date, today's offset and the January baseline are identical, and the tool reports "standard" even though Sydney is running UTC+11, which is its daylight offset. Ask about July and the same inversion bites the other way: the offsets differ, so the tool prints "DST on" for a month when Sydney is actually on plain UTC+10.

The offsets themselves are always right — they come from real zone data, and a New York 09:00 call really does land at 01:00 in Sydney in January and 23:00 the same day in July. It is only the little "DST on / standard" badge that can be trusted North of the equator and not South of it. Use the offset and the converted clock; treat the badge as a hint.

For teams spanning both hemispheres the drift is bigger than one hour. The New York–Sydney gap swings between 14 and 16 hours across the year, which is why those pairs need their own conversation rather than a template copied from a US–Europe playbook.

Worked example: a Thursday 09:00 New York call

Take the most common shape: a weekly standup, every Thursday, 09:00 New York, with one attendee in London.

In February, that call is 14:00 London — a five-hour gap. From 8 March the United States is on daylight time but Europe is not, so the same instant shows as 13:00 London. On 12, 19 and 26 March the London attendee sees 13:00. Then the EU changes on 29 March, the gap returns to five hours, and from 2 April the call is back at 14:00 London.

The autumn window is shorter but follows the same logic. From 22 October the call is still 14:00 London. On 25 October Europe falls back, so 29 October shows 13:00. On 1 November the US catches up and by 5 November the call is back at 14:00.

Notice that the meeting never genuinely changed. The local hour moved around a fixed instant, exactly as a correctly anchored recurring invite should. The drift is not a fault to be repaired; it is a property to be announced.

What to write inside the invite itself

Two small edits inside the calendar event prevent most of the confusion:

• Put the anchor time zone in the title or the first line of the description: "Thursdays 09:00 America/New_York (14:00 London, 13:00 during the 8–29 March drift)".
• Add the drift dates to the description as a standing note, so anyone opening the event at any time of year sees the windows without having to ask.

If your tool supports it, attach or link a converter view for the pair of cities so a new joiner can sanity-check the current hour in one click rather than doing mental arithmetic.

Quick checklist

• Any recurring series crossing a DST boundary has an explicit anchor time zone — not a floating local time.
• You know this year's two windows for your specific pair of regions, with dates.
• You have decided, per meeting, whether the drift is acceptable or whether the series moves.
• The decision is written in the event description, not just in your head.
• You sent one specific notice in late February, and it named the window, the direction and the resolution.
• You treat the converter's daylight-time badge with care for any zone in the Southern Hemisphere.

Mismatched DST dates are not chaos. They are a calendar event with a start date, an end date and a duration. Find the two windows, anchor your invites deliberately, and tell people what they will see — and the twice-yearly hour of confusion stops being a surprise.