Scheduling Across Time Zones: A Practical Guide for Remote Teams

Distributed teams lose an absurd amount of time to the same handful of timezone bugs: meetings that shift an hour twice a year, calendar invites that arrive at the wrong time, “9am for everyone” that isn’t. The fixes are small. The cost of not doing them is one missed product launch per year, on average.

Use IANA zones, not fixed offsets

The IANA Time Zone Database (often called tzdata or zoneinfo) is the canonical source for how clocks behave around the world. Each zone — Europe/Istanbul, America/Los_Angeles, Asia/Tokyo — is a rule: the full history of UTC offsets, DST transitions, and political changes for that location.

A bare offset like GMT+3 or UTC-5 is a value. It happens to be correct for some places at some times of year, but it doesn’t know about DST or any future legal change. Türkiye dropped DST in 2016 and moved permanently to UTC+3; UK stays on UTC+0 in winter and UTC+1 in summer. A system using fixed offsets gets this wrong silently.

Rule of thumb: every datetime stored in your database should travel with an IANA zone ID alongside the UTC instant. The zone tells you how to display it; the instant tells you when it actually happened. Our IANA timezone glossary entry covers the format in more depth.

DST handoff weeks

The single most reliable way to find timezone bugs in a calendar app is to look at the second week of March. Here’s why.

• United States moves to daylight time on the second Sunday of March and back on the first Sunday of November (since 2007).
• European Union moves on the last Sunday of March and back on the last Sunday of October.
• UK follows the EU schedule (BST starts last Sunday of March).
• Australia (eastern states)moves the opposite direction in October and April — they’re in the Southern Hemisphere.
• Japan, China, India, most of Africa, most of South America — no DST at all.

The practical fallout: between the second Sunday of March and the last Sunday of March, the US is on daylight time while Europe is still on standard time. The usual New York / London gap of 5 hours shrinks to 4. A 9am New York meeting that normally hits 2pm London hits 1pm London. Recurring meetings stored as “9am America/New_York” in a tz-aware client handle this correctly. Recurring meetings stored as “14:00 UTC” do not — they shift for European attendees and stay put for American ones.

The October handoff has the mirror problem: Europe falls back a week before the US does, briefly narrowing the gap again.

Practical overlap windows

For globally distributed teams, the question isn’t “what time works” — it’s “what window works year-round, including DST handoff weeks.” Here are the ones that survive:

US East ↔ Western Europe

13:00–17:00 UTC.That’s roughly 9am–1pm Eastern and 2pm–6pm London / 3pm–7pm Central European. Both sides are clearly in the workday, and the DST mismatch only shifts the meeting one hour earlier in local time for Europeans during handoff weeks. Avoid 17:00–18:00 UTC — engagement drops sharply once the European workday ends.

US West ↔ Western Europe

16:00–17:00 UTC. A one-hour window: 9am Pacific = 5pm London. Anything earlier loses the Europeans; anything later loses Pacific. Many teams accept this and run a single weekly sync, with everything else async.

Western Europe ↔ Asia (Tokyo, Singapore, Seoul)

08:00–10:00 UTC. 9am London = 6pm Tokyo. Early for London, end-of-day for Tokyo. Push recurring meetings to Monday or Tuesday so neither side is opening the week or wrapping it.

US West ↔ Asia

14:00–15:00 UTC.That’s 7am Pacific = 11pm Tokyo (winter). Painful for both sides. Most teams pairing these two regions skip live meetings entirely and rotate the burden when synchronous time is unavoidable.

For interactive lookup, our meeting planner shows overlap bands across multiple zones. The world clock is good for at-a-glance “is it the middle of the night for them right now?” checks.

Calendar invite traps

ICS without a TZID

The iCalendar (ICS) format that all major calendar apps speak can encode a meeting in two ways: as a UTC instant (e.g. DTSTART:20260601T130000Z) or as a local time tied to a zone (e.g. DTSTART;TZID=America/New_York:20260601T090000). The first form is unambiguous about the instant but does not shift with DST. The second form does shift, because the recipient’s client looks up the current rule for the named zone.

Recurring meetings should always use the TZID form. If you create a recurring event in a tool that stores UTC-only, every attendee outside that zone will see the meeting drift by an hour twice a year.

Outlook vs Google interpretation

Historically, Outlook would respect the originator’s timezone for display while Google would convert to the viewer’s zone. The behaviours have converged but legacy meetings (especially imports from older Outlook archives) can still show up an hour off. When a recipient reports the wrong time, the first thing to check is whether the ICS contains a TZID line.

“Floating” times

Some apps support a third form: local time with nozone, meaning “9am wherever you are.” This is correct for “take your medication at 9am” reminders and almost always wrong for shared meetings. Avoid it for team scheduling.

Practical recommendations

• Store UTC + IANA zone.Two columns: one for the absolute instant, one for the originator’s zone. Display in the viewer’s zone.
• Pick recurring meeting times by UTC band, not local time.A “13:00 UTC” weekly stays in the same overlap window all year even if it shifts in local clock by one hour.
• Audit recurring meetings around DST transitions. Block out 30 minutes the week before each transition to confirm calendar invites still land where intended.
• Default to async. The cheapest timezone fix is fewer required-attendance meetings.
• Use IANA zone names in tooling. “PST” is ambiguous (Pakistan vs Pacific vs Pitcairn). America/Los_Angeles is not.

Try the planner

Drop your team’s zones into our meeting planner to see green/red overlap bands across a 24-hour day. For one-off conversions, the time zone converter handles arbitrary date and time inputs.

Bottom line

Timezone bugs are entirely preventable. Use IANA zone names, store UTC plus zone, schedule recurring meetings by UTC band, and verify around DST handoff weeks. Most calendar-related frustration in distributed teams traces back to one of those four rules being violated. They’re cheap to follow; the alternative is missed meetings and quiet resentment.