How to Schedule Meetings Across Multiple Time Zones
Remote work has made international scheduling a daily challenge. This guide gives you a systematic framework for finding meeting windows that work across multiple time zones — without the "I thought you meant your 3 PM" problem.
Why International Scheduling Fails
The most common failure mode is the DST ambiguity problem. A recurring weekly meeting gets scheduled in January when New York is UTC−5. By March, New York has sprung forward to UTC−4, but London hasn't yet (EU changes 3 weeks later). The gap narrows by an hour for three weeks. Without a timezone-aware calendar, this shows up as an unexpected time mismatch.
The second failure mode is the "I thought you meant your 3 PM" problem. When someone says "let's meet at 3 PM" without specifying a timezone, every participant assumes it's their own 3 PM. This sounds silly but happens constantly in global teams, especially in text-based async communication where the sender's timezone isn't obvious.
The third failure mode is false precision: someone says "EST" but means EDT (they're different by an hour depending on the season), or says "IST" which can mean India Standard Time, Irish Standard Time, or Israel Standard Time depending on context.
The Five-Step Framework
Always express your proposed meeting time in UTC first. UTC never changes for DST — it is the universal constant. Instead of saying '3 PM EST,' say '20:00 UTC' and let participants convert to their local time. This eliminates all ambiguity about which version of EST/EDT/etc. you mean.
When specifying timezones, use IANA identifiers (America/New_York, Europe/London, Asia/Kolkata) rather than abbreviations. EST, IST, and BST are each shared by multiple timezones. IANA identifiers are globally unambiguous and machine-readable.
Map out working hours (typically 9 AM–6 PM) for each participant's city and find the intersection. Use a meeting planner tool for this — doing it manually with more than 3 timezones is error-prone. Even a 30-minute window can work for asynchronous-first teams that only need periodic synchronous touchpoints.
A good calendar invite includes the meeting time localized to each recipient's timezone, plus the UTC equivalent. Many calendar systems do this automatically when you add participants with different timezone settings. If yours doesn't, manually include all local times in the invite description.
If a meeting is recurring weekly, schedule a review for the first week of March, the last week of March, the last week of October, and the first week of November. These are the high-risk windows when US or EU DST transitions can silently shift your recurring meeting time.
Best Overlap Windows by Region Pair
Not all timezone pairs are created equal. Some have generous overlap; others have none during standard working hours.
In winter (UTC−5 vs UTC+0/+1): NYC afternoon is a reasonable late-day call for Europeans. 3 PM ET = 8 PM London = 9 PM Paris. In summer (UTC−4 vs UTC+1/+2): the overlap shrinks. 9 AM ET = 3 PM CEST is the practical sweet spot. Avoid Friday afternoons — Europeans tend to disconnect earlier.
IST is UTC+5:30, so when New York is at 8 AM ET (UTC−5 = 13:00 UTC), Mumbai is at 6:30 PM IST. The only overlap window is NYC early morning vs. India late afternoon. 8–9:30 AM ET = 6:30–8 PM IST. This is manageable but consistently requires the US participant to be an early riser.
CET (UTC+1) vs IST (UTC+5:30): the gap is 4.5 hours. Noon CET = 4:30 PM IST. This is the most comfortable intercontinental overlap pair — both parties are in their working day and nobody has to be up at an unreasonable hour. 12–3 PM CET = 4:30–7:30 PM IST.
PST is UTC−8; JST is UTC+9. The gap is 17 hours. When it is 9 AM Tuesday in Los Angeles, it is 2 AM Wednesday in Tokyo. Any meeting requires one side to work outside standard hours. The least bad option: 7–9 AM PT = 11 PM–1 AM JST (Tokyo works late) or 8–9 PM PT = 1–2 PM JST (Tokyo starts early). Video call dinner/breakfast setups are common.
PST (UTC−8) vs GMT (UTC+0): 8-hour gap. In winter, 9 AM PT = 5 PM GMT = 6 PM CET. Workable if Europeans stay late. In summer (PDT UTC−7 vs BST UTC+1), the gap is 8 hours again: 9 AM PDT = 5 PM BST. The consistent 8-hour gap means this is always a stretch for one or both parties.
AEST is UTC+10 (AEDT UTC+11 in summer). When LA is 8 AM PT (UTC−8 = 16:00 UTC), Sydney is at 2 AM AEST the next day. The only overlap: 6–8 PM PT = 9–11 AM AEST. This requires a late US working day. Many Australia-US teams simply rotate meeting times to share the inconvenience fairly.
The Follow-the-Sun Model for Large Distributed Teams
When a team spans Asia, Europe, and the Americas, no single meeting time works for everyone. The follow-the-sun model addresses this by structuring work so that the team "hands off" to the next region at the end of their day, rather than requiring synchronous overlap.
In a classic three-region setup: Asia-Pacific handles tasks from 8 AM to 5 PM their time, then hands off to Europe, which works until their 5 PM and passes to the Americas. With careful tooling (async video updates, shared documentation, clear handoff protocols) a team can maintain near-24-hour productivity without anyone working unreasonable hours.
Even if your team doesn't fully operate this way, the principle of "minimize synchronous dependency across large timezone gaps" is sound. Reserve live calls for decisions and relationship-building; use async (recorded video, detailed written updates, documented decisions) for information sharing.
The key operational rule: the team member in the most inconvenient timezone should receive the most thorough documentation and be the last to be expected to attend optional meetings.
Best Practices and Tools
- ✓Display your timezone prominently in your email signature, Slack profile, and calendar. This eliminates ambiguity before it starts.
- ✓Use calendar tools that display proposed times in each attendee's local timezone (Google Calendar's 'Time Zone' feature, Calendly, or World Time Buddy).
- ✓For one-off scheduling, share a link like cal.com or Calendly that shows your available slots in the viewer's local timezone automatically.
- ✓In meeting invites, include the UTC time in the description. Example: 'Tuesday 15:00 UTC (10 AM ET / 3 PM GMT / 4 PM CET / 8:30 PM IST).'
- ✓Record all meetings and share the recording with a summary document within 2 hours — this makes it easier to justify meetings being at suboptimal times for some participants.
- ✓Rotate inconvenient meeting slots so no single region always bears the cost. A monthly retrospective that always forces Sydney to join at 6 AM will damage team morale.
Frequently Asked Questions
What is the best time to schedule a call between New York and London?
In winter (EST): 2–5 PM New York = 7–10 PM London. In summer (EDT): 9 AM–12 PM New York = 2–5 PM London. The afternoon New York / early evening London window is generally the most comfortable for both parties. Avoid Monday mornings and Friday afternoons for important calls — productivity drops on both ends.
How do I avoid the DST confusion when scheduling recurring meetings?
Use calendar software that respects IANA timezone data (Google Calendar, Outlook, and most modern tools do this). When creating a recurring invite, specify the timezone explicitly (e.g., "America/New_York" rather than "Eastern Time"). The software will then shift the absolute time automatically when DST transitions occur. Then review the first week of March, last week of March, last week of October, and first week of November each year for the US-Europe corridor.
Is there any time that works for all major global regions?
No single time slot is convenient for everyone. The least-painful universal option is typically 7–9 AM Pacific / 10 AM–12 PM Eastern / 3–5 PM London / 4–6 PM Central Europe / 8:30–10:30 PM India / 12–2 AM Tokyo (next day). Tokyo and Sydney typically require someone to work outside normal hours in any global all-hands. Most global teams with Asia-Pacific participants schedule a separate Asia-Pacific-friendly session or rotate the inconvenience.
What does "UTC anchor" mean in practice?
When you "anchor to UTC," you define the meeting in terms of its UTC time first — for example, "this meeting is at 14:00 UTC." All participants then convert that to their local time. Because UTC never changes for DST or any other reason, 14:00 UTC is always the same absolute moment in time, regardless of the season. This makes it the safest reference point for scheduling across regions with different DST rules.
Related Tools
Use our Meeting Planner to find overlap windows across multiple timezones, or the Timezone Converter to check current offsets.