How DST affects business meetings across continents
If you have a recurring meeting with someone in a different region, DST will eventually mess it up. Twice a year, your zones shift on different weekends, and meeting times that "always" worked suddenly happen at unexpected hours. Most professional confusion around DST happens in those gap weeks.
For checking specific time differences across the year, the meeting planner handles all DST shifts automatically.
The basic problem
Your time zone shifts on one weekend. Your colleague's zone shifts on a different weekend. For a few weeks, the time difference between your zones is "wrong" by an hour.
Examples:
US-EU spring gap. The US shifts to DST on the second Sunday of March. The EU shifts on the last Sunday of March. For 2-3 weeks in March, the time difference between New York and London is 4 hours instead of the usual 5.
US-EU fall gap. The US shifts back from DST on the first Sunday of November. The EU shifted back the previous Sunday (last Sunday of October). For 1 week in late October/early November, the difference is 4 hours again.
US-Australia mismatch. Australia's DST runs October to April (their summer). The US runs March to November. For about 6 months a year, the time difference between New York and Sydney is "off" by 2 hours from the simple offset math.
Why this matters
A recurring meeting between New York and London "every Tuesday at 3 PM ET" works fine most of the year. During the gap week, 3 PM ET is now 4 PM London time (instead of 8 PM). Your London colleague shows up an hour earlier than expected, or you both join at different times confused about whose calendar is right.
The deeper bug: if your calendar invite specifies "3 PM ET," it travels with that explicit time zone. Most calendars handle the conversion correctly. But if the meeting was originally created during ET-summer-time and you're now in ET-winter-time, the calendar might display the wrong meeting time.
The fix: anchor to UTC
Best practice for recurring cross-region meetings: pick a UTC anchor.
Instead of "every Tuesday at 3 PM ET," pick "every Tuesday at 19:00 UTC." UTC has no DST, so the meeting is at the same UTC moment year-round.
In Google Calendar:
1. Create a new meeting
2. Click the time zone selector (next to the date/time)
3. Pick "(UTC) Coordinated Universal Time"
4. Set the meeting time
Outlook, Apple Calendar, and most calendar apps work similarly.
The trade-off: in your local zone, the meeting will appear at different times during the year. "Every Tuesday at 19:00 UTC" looks like 14:00 ET in winter and 15:00 ET in summer. You see the shift; your colleague sees their version of the shift. But the meeting itself is at the same UTC moment regardless of season.
Specific gap windows to watch
| Region pair | Gap window | Typical normal diff | Gap-week diff |
|-------------|-----------|---------------------|---------------|
| US East ↔ EU | Mid-March (2-3 weeks) | 5 hours | 4 hours |
| US East ↔ EU | Late October-early November (1 week) | 5 hours | 4 hours |
| US ↔ Australia | March-April | 14-17 hours (depends on city) | shifts by 1-2 hours |
| US ↔ South America | Most of year | 0-3 hours | varies |
| EU ↔ Asia (no-DST) | Mid-March, late October | varies | shifts by 1 hour |
The biggest single confusion source is the US-EU spring gap. It happens every year. Most multinational businesses have learned to anchor recurring meetings to UTC because of this.
What to do during a gap week
If you're in a gap week and a meeting is happening:
Option A — accept the new time. Sometimes the meeting really does shift in someone's local time. If your calendar says it's at 4 PM London now (instead of 5 PM), and that works, just go with it.
Option B — explicitly reschedule. Change the meeting time for that one week. Most calendars allow editing a single occurrence of a recurring meeting.
Option C — switch to UTC anchor going forward. If this gap week creates serious confusion, this is the moment to fix the recurring meeting permanently.
Cross-checking before the shift
A useful habit: in the week before each DST shift (so, second weekend of March or first weekend of November in the US), audit your recurring meetings for the next 3 weeks. Check that:
- The meeting time is what you expect for everyone's local zone
- If anyone is in a region with different DST rules, the time will shift correctly
- Your calendar's time zone setting matches your physical location
Catching a misalignment in advance is much cheaper than dealing with a confused team during the actual gap week.
Tools that help
Google Calendar's "World Clock" sidebar. Add cities of frequent collaborators. You see all their local times next to your calendar.
Outlook's "Time Zone" picker per meeting. Pick the zone the meeting "lives" in. Outlook handles conversion to attendees' local zones.
Slack's status hours. Set your "working hours" so Slack shows away after business hours. Helps colleagues respect your time zone.
The meeting planner. Pick cities, see overlap windows for any date including DST shifts.
The time converter for one-off conversions when scheduling new meetings.
Edge cases
Multi-zone teams. If your team includes attendees from multiple regions with different DST schedules, gaps can affect different attendees on different weekends. There's no perfect anchor — pick one zone (often the host's or the largest team's) and accept that others will see shifts.
Recurring training sessions or webinars. If you offer the same training across regions, schedule each region's session separately rather than one global session. The math gets unmanageable otherwise.
Conference scheduling. International conferences often publish times in UTC and let attendees convert to local. This is the cleanest approach.
Asynchronous teams. If your work is fully async, DST shifts matter less. The meeting time is "whenever you can join the recording," not "show up at this exact moment."
A worked example
Say you have a weekly meeting between Mumbai (UTC+5:30, no DST) and London (UTC+0 winter, UTC+1 summer):
- Winter (Oct-Mar): Mumbai is 5:30 ahead of London
- Summer (Mar-Oct): Mumbai is 4:30 ahead of London
If your meeting is "every Tuesday at 3 PM IST," that's:
- Winter: 9:30 AM London
- Summer: 10:30 AM London
The London attendee sees a 1-hour shift twice a year. They might expect it (Mumbai doesn't have DST so they know it's the London side that shifts), or they might not.
If you anchor to UTC: "every Tuesday at 09:30 UTC" is consistent. In Mumbai it's always 3 PM IST. In London it's 9:30 AM in winter and 10:30 AM in summer (London accepts the shift since they're the ones whose zone is shifting).
FAQ
Why doesn't my calendar handle DST automatically?
It does, mostly. The bug is usually in how the meeting was originally created — without a specified time zone. Calendar apps then default to the device's current zone, which travels with you and creates ambiguity.
Should I always anchor recurring cross-region meetings to UTC?
If you're sure all attendees can mentally convert UTC to their local time, yes. If not, anchor to the time zone of the largest group of attendees and explain in the meeting invite that it shifts twice a year.
What if I'm scheduling for next week but my calendar is showing old DST behavior?
Make sure your operating system has the latest tz database. iOS/Android/Windows all push tzdata updates with normal OS updates. Older OS versions can have stale rules.
Why does the EU shift later than the US in spring?
Different regulations. The US uses "second Sunday of March." The EU uses "last Sunday of March." That's 2-3 weeks apart in most years. The decisions were made independently.
Will the EU and US ever align DST schedules?
Unlikely. Aligning would require both regions to agree on a date. The current rules have been in place for decades. Each region would need a legislative change to align with the other.
What about countries that don't observe DST?
Their offset to UTC stays constant. Indian colleagues are always UTC+5:30. Chinese colleagues always UTC+8. The shift confusion only affects DST-observing zones.
Bottom line
DST schedules don't align across regions, creating 1-3 weeks per year of recurring-meeting confusion in the gap windows. The cleanest fix is to anchor recurring cross-region meetings to UTC. Most calendars support this; switching takes seconds and prevents twice-yearly chaos.
For specific time differences and overlap windows on any date, the meeting planner handles all the DST math.