TTimeForge
Get TimeForge

TimeForge/Guides

Find the Best Meeting Time for Multiple Time Zones

Learn how to calculate optimal meeting slots for distributed teams using working-hour overlays and timezone-aware links.

September 28, 2026 · 7 min read

The best meeting time for distributed teams is the narrowest window where all members are within their standard working hours, typically found by comparing local start and end times against a common reference like UTC. For a team spanning New York, London, and Tokyo, the optimal slot is usually between 13:00 and 14:00 UTC, which translates to early morning in New York, early afternoon in London, and evening in Tokyo. This approach ensures everyone is awake and active without forcing anyone into unreasonable hours.

Why Standard Time Conversion Fails Distributed Teams

Most people try to schedule meetings by converting times one by one in their heads or using basic calculator apps. This method breaks down when you have three or more time zones because you are essentially solving a system of inequalities manually. You might find a time that works for New York and London, only to realize it is midnight in Tokyo. Or you might pick a time that suits Tokyo and London, but is too early for New York.

The failure point is that simple conversion does not account for the "working hour" constraint. Being awake is not the same as being available for work. A time might be technically convenient (everyone is awake) but practically poor (one person is commuting, another is eating lunch, another is just waking up). Effective scheduling requires identifying the intersection of working hours, not just waking hours. This distinction is critical for maintaining productivity and respecting boundaries across regions.

Step-by-Step: Mapping Team Working Hours

To find the right slot, you must first define the boundaries for each location. Do not guess; use standard business hours for each city unless your team has specific flexible arrangements. For our example team, we assume:

Next, convert these local windows to UTC to compare them on a single timeline. This is the most reliable method because UTC does not change with daylight saving time adjustments in the same way local clocks do, providing a stable baseline.

New York (EST): UTC-5.

London (GMT): UTC+0.

Tokyo (JST): UTC+9.

Now, look for the overlap. London is available from 09:00 to 17:00 UTC. Tokyo is available from 00:00 to 09:00 UTC. The only time London and Tokyo overlap is exactly at 09:00 UTC. However, New York does not start working until 14:00 UTC. There is no common window where all three are within their standard 9-to-5 blocks. This reveals the core challenge: rigid standard hours often leave no common slot for global teams. You must look for "shoulder" hours where people are likely to be flexible.

Using Overlays to Identify True Overlaps

When standard hours do not align perfectly, you need to visualize the "soft" boundaries. Most remote workers are active slightly before their official start time and slightly after their end time. By extending the window by one hour in each direction, you create a realistic availability overlay.

Let's adjust our example windows to include reasonable flexibility:

Now, find the intersection:

  1. London is active from 08:00 to 18:00 UTC.
  2. New York is active from 13:00 to 23:00 UTC.
  3. Tokyo is active from 23:00 to 10:00 UTC (wrapping around midnight).

The overlap between London and New York is 13:00–18:00 UTC. Does this fit Tokyo? Tokyo is awake until 10:00 UTC and starts again at 23:00 UTC. There is a gap between 10:00 and 23:00 UTC where Tokyo is asleep. This suggests that a mid-day UTC meeting is difficult for Tokyo unless they are willing to start very early.

If Tokyo shifts to a later start (common in some Asian tech hubs), say 10:00 AM JST (01:00 UTC), their window becomes 01:00–11:00 UTC. Now compare:

The intersection of London and Tokyo is 08:00–11:00 UTC. Does New York fit? New York starts at 13:00 UTC. Still no overlap. The gap is persistent because New York is significantly west of London and Tokyo is significantly east. The best compromise is often the edge of the windows. A meeting at 13:00 UTC works for New York (start of day) and London (mid-afternoon). For Tokyo, 13:00 UTC is 10:00 PM. This is late, but often acceptable for a short sync if it is the only bridge.

Tools like TimeForge automate this overlay logic. Instead of manually converting each hour, you add the three cities. The interface displays a horizontal timeline where green zones indicate hours where all three are awake and working, yellow for acceptable shoulder hours, and red for late-night/early-morning conflicts. For our example, it would highlight the narrow band around 13:00 UTC as the optimal compromise, ranking other slots lower based on how far they push participants outside their comfort zones.

Handling DST and Holiday Variations

Daylight Saving Time (DST) changes break static calculations. If you set a meeting for 9:00 AM EST, and New York switches to EDT (UTC-4), the UTC time changes from 14:00 UTC to 13:00 UTC. If you have hardcoded the UTC offset, your meeting time will be wrong for half the year.

Always use IANA timezone identifiers (like America/New_York, Europe/London, Asia/Tokyo) rather than fixed offsets. These identifiers contain rules for when DST starts and ends. When you select these cities in a scheduler, the system automatically adjusts the relative offsets as the calendar progresses.

For example, in November, London remains on GMT while New York switches from EDT to EST on the first Sunday. During the week before this switch, the difference between the two cities is four hours; after the switch, it returns to five hours. Using named zones ensures that these shifts are handled correctly without manual recalculation. Holiday variations also matter; if Tokyo has a national holiday, their working hours might shift or shorten. A good scheduler pulls these calendar events into the availability logic, marking those days as lower priority or unavailable.

Once you identify the slot, communicating it clearly prevents confusion. Do not send a message saying "Meet at 2 PM GMT." This requires every recipient to convert that time mentally. Instead, use a link that renders the time in the viewer's local timezone automatically.

If you use a tool that supports shareable links, you generate a URL that contains the UTC timestamp and the timezone metadata. When a colleague in Tokyo clicks the link, it displays "10:00 PM JST." When a colleague in New York clicks the same link, it displays "8:00 AM EST." The underlying data is identical, but the presentation is personalized.

This eliminates the "wait, what time is that for me?" back-and-forth. It also ensures that if someone travels and changes their device timezone, the link updates automatically to reflect their new location. For teams that do not use such tools, a simple table in the email body is the fallback. List the city, the local time, and the UTC time. Keep it concise.

LocationLocal TimeUTC Time
New York8:00 AM EST13:00 UTC
London1:00 PM GMT13:00 UTC
Tokyo10:00 PM JST13:00 UTC

Common Pitfalls in Global Scheduling

Avoid these frequent mistakes to streamline your scheduling process.

Ignoring the "Shoulder" Hours Many teams insist on strict 9-to-5 alignment. This often results in no viable meeting time. Accept that for global teams, meetings often happen at the edges of the day. A 7:30 AM start in New York might be perfectly fine if it allows a reasonable finish time in Tokyo, accounting for the significant time difference. Communicate this expectation clearly.

Forgetting DST Transitions Set recurring meetings with named timezones, not fixed offsets. If you set a meeting for "Every Monday at 9 AM," ensure your calendar app knows which timezone "your" 9 AM refers to relative to the others. If you use a fixed UTC time, check the offset every few months when clocks change.

Overlooking Commute Times Some cultures have long commutes. A meeting at 8:00 AM might be technically "working hours" but practically difficult if the employee is on a train. Check if your team members have specific "no-meeting" windows due to commute or family logistics. Adjust the overlay accordingly.

Assuming Uniform Availability Not everyone has the same working hours. A developer in London might start at 8 AM, while a designer in New York starts at 10 AM. Do not assume a standard block applies to everyone. Input actual individual preferences if possible. This creates a more accurate overlap map and reduces friction when scheduling.

Do it in TimeForge

Everything in this guide works in the browser — open the tool and try it on your own input.

Open TimeForge →

Questions people also ask

How do I handle Daylight Saving Time changes?

Use UTC as your fixed reference point because it does not change with daylight saving adjustments, ensuring your calculated overlap remains stable. Convert each member's local start and end times to UTC once, then compare those fixed UTC windows to find the intersection regardless of seasonal clock shifts.

Can I save my team's timezone setup for later?

Yes, most scheduling tools allow you to save specific time zone combinations or recurring meeting slots to avoid recalculating overlaps. This ensures consistency for regular syncs without needing to manually verify the UTC intersection for every new meeting.

Does the link show different times for each person?

Yes, modern scheduling links automatically detect each participant's local time zone and display the meeting time in their specific local format. This eliminates manual conversion errors and ensures everyone sees the correct start time for their location.

What if someone works non-standard hours?

Adjust their specific availability window in the calculation to reflect their actual working hours rather than the standard 9-to-5 block. The intersection logic remains the same, but you must use their personalized start and end times to find the true overlap with other team members.