How to Schedule Meetings Across Time Zones

Finding workable overlap windows, communicating times without ambiguity, and keeping everyone on schedule — even when clocks change.

Scheduling a meeting across time zones is one of those tasks that looks simple until it isn't. Convert a single time, confirm everyone received the same information, account for daylight saving time changes, and you're done — in theory. In practice, the edge cases multiply quickly. This guide covers how to approach the whole problem, from finding a workable window to preventing last-minute confusion when clocks change.

Step 1: Map Your Time Zones First

Before opening a calendar tool, list every location involved. Note whether each zone currently observes daylight saving time and when their clocks next change. This matters because the gap between zones can shift by an hour at DST boundaries — and different countries change on different dates.

As a quick example: in early November, the United States falls back one hour, but the UK already fell back one week earlier. For roughly one week, the gap between New York and London is five hours instead of the usual four. A standing meeting set for "9 AM New York / 2 PM London" will appear in London calendars as 1 PM for that one week — if the invitation was written with a fixed UTC offset rather than a named time zone.

Always specify a named time zone, not just an offset. Write "9:00 AM Eastern Time (New York)" rather than "9:00 AM UTC-5." The named zone tells calendar software when to adjust for DST automatically.

Step 2: Find the Overlap Window

Most teams have a smaller useful window than they realize. If you're working across North America, Europe, and Asia simultaneously, there may be no single hour that falls within standard business hours (roughly 9 AM–6 PM) for everyone.

A practical framework for finding overlap:

  1. List "acceptable" hours for each participant — not just business hours, but the window they're genuinely available (some people prefer early mornings; others are flexible in the evening).
  2. Convert each window to UTC to find common ground without juggling multiple offsets.
  3. Pick a time within the UTC overlap. Use a tool like this converter to confirm what that UTC time looks like for each participant.
  4. If there's no overlap, rotate the inconvenient time slot. Don't always schedule to suit the largest or most senior time zone at the expense of others.

Common Overlap Windows

Common overlap windows between major regions
Region Pair Useful Overlap (approx.) Notes
US East + US West9 AM–3 PM PT / 12–6 PM ETFull business hour overlap
US East + London9 AM–1 PM ET / 2–6 PM GMTShifts by 1 hr at DST boundaries
London + Central Europe9 AM–5 PM — mostly aligned1-hr gap, easy to schedule
US East + India7–10 AM ET / 5:30–8:30 PM ISTEarly US / evening India
US West + TokyoVery limited — 8–10 AM PST / 1–3 AM JST next dayOne side always sacrifices
London + Singapore9–11 AM GMT / 5–7 PM SGTSmall but usable window
US East + Sydney8–9 AM ET / 10–11 PM AEST (next day)One slot; both stretch

Step 3: Send the Invitation Correctly

Calendar invitations handle time zones automatically when set up correctly, but there are common pitfalls:

  • Use your calendar tool's time zone field. In Google Calendar, Outlook, and Apple Calendar, you can specify the time zone for an event — don't leave it as "local." Set it to your zone and let the tool convert for recipients.
  • Include the time zone in the subject or description. Even with automatic conversion, it's good practice to write the time explicitly: "Weekly sync — Thursdays 10:00 AM Eastern / 3:00 PM GMT / 11:00 PM SGT." This eliminates confusion if someone views the invite on a device with wrong system settings.
  • Add a time zone converter link. Link to besttimeconverter.com/converter.html in the invite body so attendees can verify the conversion for themselves.

Step 4: Account for DST Transitions

Recurring meetings need special attention at DST boundaries. When you create a recurring event in a modern calendar application, the system handles future occurrences automatically using named time zones — so "9 AM Pacific" will always be 9 AM Pacific, whether that's UTC-8 or UTC-7 at any given date.

However, problems arise when meetings are manually scheduled with fixed UTC offsets, or when participants are in regions that change clocks on different dates. In those cases, the gap between two zones changes for a week or two each spring and autumn.

For meetings that span regions with different DST schedules, consider:

  • Confirming the meeting time the week before and after a DST boundary
  • Using an agenda tool or Slack message to send a reminder with converted times during transition weeks
  • Choosing a UTC-based meeting time for highly international groups (UTC never changes)

Step 5: Build Good Habits for the Long Term

One-off meetings are manageable. Recurring meetings with rotating attendance across multiple zones require more structure:

  • Keep a shared world clock. Pin a world clock widget to your team's communication tool (Slack, Teams) showing all relevant time zones. This reduces the cognitive load of constant conversion.
  • Rotate difficult time slots. If someone always takes a 7 AM call, that's worth rotating. Fair rotation builds goodwill and prevents burnout among those in difficult zones.
  • Record or document meetings. For teams with a span so wide that no reasonable overlap exists, asynchronous updates with recorded summaries reduce pressure on synchronous scheduling.
  • Use UTC for technical coordination. Log timestamps, deadlines, and deployment windows in UTC. Team members convert to local time on their end. This avoids ambiguity in written records.

Quick Reference: Scheduling Across Zones Checklist

  • ✓ Mapped all participants' time zones
  • ✓ Identified the useful overlap window using UTC
  • ✓ Verified conversions with a time zone tool
  • ✓ Invitation uses named time zones, not UTC offsets
  • ✓ Time zone written explicitly in invitation body
  • ✓ Recurring meetings checked around DST transition dates
  • ✓ Inconvenient slots rotated fairly across the team