How to Schedule Meetings Across Three Time Zones
Short answer: Three-zone meetings rarely have a window where everyone is in standard working hours. Pick a fair rotation, default to the narrowest natural overlap (often 30–60 minutes), and use async writeups for anything that does not need a live discussion.
A team that spans New York, London, and Bangalore covers a 14-hour spread. Even if every member stretches their day, the live overlap is short. The question is not which hour works for everyone — it is which compromise the team is willing to accept and how to keep one region from absorbing all the inconvenience.
Step 1 — Map the working hours
Write down each region's normal working day in its own local time, then convert each to a common reference (UTC works well). Where the three windows overlap is the only time everyone is inside ordinary hours. For most Americas–Europe–Asia teams, that overlap is 30–90 minutes wide, not several hours.
Step 2 — Decide the meeting's purpose
- Decisions or unblockers: Schedule live, inside the natural overlap.
- Status updates and FYIs: Replace with async written updates.
- Working sessions: Shorter sessions, more often, inside the overlap window.
Step 3 — Anchor and rotate
Pick one region as the anchor for each recurring meeting and book in that region's local time. Rotate the anchor over time so each region absorbs the inconvenience in turn. Document the rotation so people know when their out-of-hours week is coming.
Step 4 — Buffer the DST weeks
US, UK, and EU DST transitions do not align. India does not observe DST. The practical effect is that recurring three-zone meetings can shift by an hour for a week or two in March and October. Reconfirm the meeting time around those transitions so nobody shows up at the wrong hour.
Step 5 — Make async the default
The honest version of three-zone scheduling is that most meetings should not be meetings. Standardise written updates, recorded video walkthroughs, and clear comment windows in shared docs. Keep live time for the things that actually need live time.
Worked examples
The three scenarios below show what three-zone scheduling looks like in practice. Each one uses real offsets and names the compromise honestly.
Example 1: New York / London / Bangalore
The spread: New York (EST/EDT) is five hours behind London (GMT/BST), which is four and a half hours behind Bangalore (IST). The total spread is roughly nine and a half hours.
The problem: At 09:00 New York, London is at 14:00 (comfortable) and Bangalore is at 19:30 (past the working day for most people). At 11:00 New York, Bangalore is at 21:30. There is no window where all three are between 09:00 and 18:00 local time.
Realistic window: 09:00–10:30 New York / 14:00–15:30 London / 19:00–20:30 Bangalore. New York and London are comfortable; Bangalore is working early evening.
Who compromises: Bangalore. There is no way to avoid it given the spread. A rotation where Bangalore gets the afternoon slot some weeks (requiring New York to meet at 04:30–06:00) is possible but rarely sustainable. The more practical choice is to accept that Bangalore works early evening for live calls, keep those calls short, and compensate with written async updates that arrive before Bangalore's morning.
DST note: During the spring and autumn DST gaps, the New York–London offset drops from five to four hours for about two weeks. That shifts the Bangalore window by one hour — worth re-checking in mid-March and late October.
Relevant converters: New York → London · EST → IST
Example 2: San Francisco / London / Tokyo
The spread: San Francisco (PST/PDT) is eight hours behind London (GMT/BST), which is nine hours behind Tokyo (JST). The total spread is seventeen hours — more than two-thirds of a day.
The problem: When San Francisco opens at 09:00, London is at 17:00 (end of day) and Tokyo is at 02:00 the next morning. When Tokyo opens at 09:00, London is at midnight and San Francisco is at 16:00 the previous afternoon. There is no single hour where all three cities are inside standard working hours.
Realistic approach: Split the meeting into two calls rather than one. A San Francisco–London call at 09:00 SF / 17:00 London catches London at the end of its day while San Francisco is fresh. A separate London–Tokyo call at 08:00 London / 17:00 Tokyo catches Tokyo at the close of its day while London is starting. A written handoff between the two calls keeps Tokyo informed without anyone joining at 02:00.
Who compromises: London anchors both calls, which means London hosts two calls at the edges of its day. Rotate the anchor to San Francisco or Tokyo for one of the calls periodically to balance the load.
DST note: Tokyo does not observe DST. The San Francisco–London gap moves by one hour in spring and autumn, which means the San Francisco–London call window shifts slightly during those weeks.
Relevant converters: San Francisco → London · Los Angeles → Tokyo
Example 3: Berlin / Dubai / Sydney
The spread: Berlin (CET/CEST) is three hours behind Dubai (GST), which is six hours behind Sydney (AEST/AEDT). The total spread is nine hours.
The problem: At 09:00 Berlin, Dubai is at 12:00 (comfortable) and Sydney is at 18:00 (end of day). At 08:00 Berlin, Sydney is at 17:00 — the last slot that keeps Sydney inside working hours, with Berlin starting one hour early.
Realistic window: 08:00–09:00 Berlin / 11:00–12:00 Dubai / 17:00–18:00 Sydney. This is a one-hour window at best, and it requires Berlin to start early and Sydney to stay until close of day.
Who compromises: Berlin and Sydney split the inconvenience — Berlin starts slightly early, Sydney finishes late. Dubai sits in the middle and is comfortable throughout. A rotation that occasionally moves the call to 10:00 Berlin / 13:00 Dubai / 19:00 Sydney (Sydney bears more) or to 07:00 Berlin / 10:00 Dubai / 16:00 Sydney (Berlin bears more) keeps the load shared.
DST note: Neither Dubai nor Sydney (AEST) observes Northern Hemisphere DST. Berlin switches to CEST in late March and back in late October, which shifts the gap to Dubai and Sydney by one hour. Sydney observes its own summer time (AEDT, UTC+11) from late October to early April, which can widen or narrow the Berlin–Sydney gap depending on the time of year. Check the live converter during October and March transitions.
Relevant converters: Dubai → London · Berlin → New York
Frequently asked
What is the typical overlap for the Americas, Europe, and India?
Roughly 30–90 minutes around 09:30–10:30 New York / 14:30–15:30 London / 19:00–20:00 Bangalore. The exact window shifts by an hour during DST gaps in March and October.
Should one region always host the meeting?
No. A rotation is more sustainable. Anchor each meeting to one region's working hours and rotate the anchor week to week or month to month so the same team is not always working late or early.
What if no overlap exists at all?
Replace the meeting with a structured async update: written status, recorded video, or a shared document with a 24-hour comment window. Save synchronous time for decisions that genuinely need a live conversation.
How does this change with daylight saving time?
The overlap can move by an hour for two short windows each year when one region switches and others have not. Re-confirm the recurring meeting time around mid-March and late October.
Is it better to split a three-zone meeting into two separate calls?
Often yes. A SF–London call at 09:00 SF / 17:00 London and a separate London–Tokyo call at 08:00 London / 17:00 Tokyo is less exhausting than forcing all three onto one call where someone is always at an extreme hour. Use a written handoff between the two calls.