Quick answer: Daylight Saving Time breaks recurring cross-border meetings because two regions change their clocks on different weekends, so the offset between them shifts for a week or three each spring and autumn. A "recurring 3 PM" call silently lands an hour early or late for one side until both regions finish transitioning. The fix is to store meetings anchored to a specific time zone (not a bare clock time), agree on one "source" zone for the team, and re-confirm standing calls around the four transition dates each year.
Sanity-check any meeting in five seconds: Open BestSyncTime, enter both cities, and the Overlap Dial shows the live offset - so you catch a DST shift before it turns into a missed call.
Why a "fixed" meeting time isn't actually fixed
Here's the trap almost everyone falls into: you set a recurring meeting for "3:00 PM," think of it as a permanent, unchanging slot, and assume it means the same thing all year. For a single-city team, it does. For a cross-border team, it doesn't - and the reason is worth understanding, because it changes how you should set meetings up.
When you create a recurring event, your calendar stores it as a clock time in one time zone (usually the organizer's). For every occurrence, it then calculates what that translates to in each attendee's zone, using the offset in effect at that moment. That's normally the behavior you want - it's what keeps a 9 AM local standup at 9 AM local even across a clock change.
The problem appears when the two zones don't change clocks on the same day. During that gap, the offset between them is temporarily different, so the translated time moves for one side - even though nobody touched the invite.
A concrete walk-through
Let's make it real with a London-New York standing call in 2026.
A London manager sets a recurring meeting for 3:00 PM London time with a New York colleague. For most of the year, London and New York are five hours apart, so that's 10:00 AM in New York. Everyone's happy.
Then March 8, 2026 arrives. New York springs forward to daylight time, but London doesn't change until March 29 - three weeks later. During those three weeks, the gap between the cities is only four hours instead of five. So the same 3:00 PM London slot now translates to 11:00 AM New York, not 10:00.
The London manager sees no change - it's still "3 PM my time." But the New York colleague's calendar now shows 11 AM. If they'd mentally locked onto "our call is at 10," they show up an hour late (or block the wrong hour). Three weeks later, on March 29, London springs forward too, the gap returns to five hours, and the call snaps back to 10 AM New York - with no announcement.
The same thing happens in reverse each autumn, during the October 25-November 1 window when Europe has fallen back but the US hasn't. Two disruptions a year, every year, on the same team.
Why it feels like the calendar is "broken" when it isn't
The frustrating part is that the software is doing exactly what it's designed to do. It's faithfully translating a fixed London time into the correct New York time for each date. The "bug" is in the human assumption that the other person's clock time never moves.
Understanding this flips the fix from "how do I stop my calendar misbehaving?" to "how do I set meetings up so the shift is expected and visible?" You can't stop DST; you can make your scheduling resilient to it.
Before every transition week, do one check: pull the pair up in BestSyncTime and note the current gap. If it's changed from last week, you know a recurring call has moved - and you can warn the team before anyone misses it.
The fixes, in order of impact
1. Anchor every cross-border event to a time zone
When creating an event, use your calendar's "time zone" option to attach the meeting to a specific zone (say, America/New_York). Most modern calendar apps - Google Calendar, Outlook, Apple Calendar - support this. It ensures every occurrence resolves from the same anchor, so the behavior is predictable and consistent for everyone rather than depending on whose device created the invite.
2. Agree on one "source of truth" zone for the team
Distributed teams should pick a single reference zone - often where the most people or the headquarters sit - and express all shared times in it. "Standup is 9 AM Eastern" is unambiguous; "standup is 9 AM" is not. This doesn't prevent the offset from shifting, but it gives everyone one clock to translate from, which drastically cuts confusion.
3. Mark the four transition dates
Put the 2026 change dates on your calendar as all-day reminders: - March 8 - US springs forward (US/EU gap shrinks until March 29) - March 29 - Europe springs forward (gap back to normal) - October 25 - Europe falls back (gap shrinks until November 1) - November 1 - US falls back (gap back to normal)
Just seeing these flags prevents most mistakes, because you'll instinctively double-check cross-border calls that week.
4. Re-confirm standing meetings around the windows
A one-line message - "confirming our Tuesday sync is still 10 AM your time next week?" - in the days before and after each transition catches any drift before it costs someone a meeting. It takes ten seconds and saves a lot of "were we supposed to meet?" confusion.
5. Beware the Southern Hemisphere reversal
If your team includes Australia or New Zealand, remember their clocks move the opposite direction on their own dates (they spring forward in October, fall back in April). A US-Australia meeting can swing by up to two hours across the year, and there are windows where both hemispheres are transitioning at once. For these, checking a live converter isn't optional - the mental math has too many moving parts.
A simple pre-meeting habit that prevents all of this
If you adopt one thing from this article, make it this: during any transition week, verify cross-border meeting times against a converter before the first call of the day. The four danger weeks in 2026 are March 8-29, and October 25-November 1. Outside those windows, your normal offsets hold and you can relax. Inside them, assume every cross-border recurring meeting has potentially moved by an hour until you've confirmed otherwise.
This is exactly the kind of narrow, predictable failure that's easy to defend against once you know it exists - and invisible until it bites you.
The bottom line
DST breaks recurring meetings not because your calendar is malfunctioning, but because two regions change clocks on different weekends, shifting the offset between them for a week or three each season. A fixed local time on one side becomes a moving time on the other. Defend against it by anchoring events to a time zone, agreeing on one reference zone, marking the four transition dates, re-confirming standing calls around them, and checking a converter during the danger windows. Do that, and the twice-a-year scramble simply stops happening to your team.
Make it automatic: Open BestSyncTime, add every city on your team, and drag the Overlap Dial to see everyone's real shared hours - DST already applied, no arithmetic required.