Why recurring cross-timezone meetings break twice a year
Not every country changes clocks, and those that do don't change on the same day. That gap is where recurring meetings quietly break.
A recurring cross-timezone meeting that has worked fine for months will, on a specific week each spring and each autumn, suddenly be an hour off for half the attendees. Nothing was changed. This is the single most common way cross-timezone scheduling fails, and it is entirely predictable.
The mechanism
A recurring calendar event is anchored to a wall-clock time in one timezone — usually the organiser's. When that zone shifts for daylight saving, the event follows it, and the gap to every other zone changes by an hour. If the other zone shifts on the same date, the two cancel out and nobody notices. If it shifts on a different date, or doesn't shift at all, the meeting moves for one side and stays put for the other.
The dates genuinely differ. Europe and North America don't switch on the same weekend, which leaves a stretch of weeks each year when transatlantic meetings are an hour off their usual gap. Many zones — India, Japan, most of Africa, much of South America — don't observe daylight saving at all, so they absorb the full shift every time their counterpart moves. Southern-hemisphere zones shift in the opposite direction from northern ones, which means the gap can move by two hours rather than one.
What to do about it
- Always create recurring events as real calendar entries with a named timezone, never as a fixed UTC offset. 'UTC+1' is correct for part of the year; 'Europe/London' is correct always.
- Put transition weeks in your calendar as a reminder to re-check the meeting, rather than trusting that it will hold.
- When a meeting is close to the edge of someone's day, treat the shift as guaranteed breakage. A 17:00 finish that becomes 18:00 for one side is a real change, not a rounding error.
- For anything scheduled more than a few weeks ahead, confirm the actual local times for that specific date rather than assuming today's gap still applies.
Why this tool doesn't have the problem
Every city here carries its IANA timezone identifier rather than a fixed offset, and every calculation runs against the date you actually choose. Pick a date on the far side of a transition and the timeline redraws with the offsets that will really be in force then — including the cases where two zones have swapped their relative order. The pair pages state, for each pair, whether the gap is fixed all year or moves, and by how much.