TTimeForge
Get TimeForge

TimeForge/Guides

Best Meeting Times for Global Audience

Learn how to find optimal meeting slots for distributed teams across time zones using overlap analysis and smart scheduling tools.

October 17, 2026 · 6 min read

The best meeting time for a globally distributed team usually falls between 13:00 and 15:00 UTC. This window typically captures the late morning in North America, the mid-afternoon in Europe, and the evening in East Asia, creating the smallest compromise across major business hubs. While no single hour is perfect for every continent, this range offers the highest probability of synchronous availability for teams spanning these three regions.

Calculating the Overlap Window

To find the optimal slot, you must convert each participant’s local working hours into a common reference, typically UTC. Most professionals work from 9:00 AM to 5:00 PM local time. When you map these windows onto a single timeline, you look for the intersection where all parties are awake and available.

Consider a team with members in New York, London, and Tokyo. The time zones shift based on the season due to Daylight Saving Time (DST). For a summer meeting in June, the offsets are typically UTC-4 for New York, UTC+1 for London, and UTC+9 for Tokyo.

Here is how the working hours translate to UTC for a June meeting:

Strictly speaking, there is no overlap between Tokyo’s standard working hours (ending at 08:00 UTC) and New York’s start time (beginning at 13:00 UTC). This creates a gap. To bridge this, teams often rely on flexible hours. If the Tokyo colleague starts early (8:00 AM local = 23:00 UTC previous day) or stays late, and the New York colleague starts early, a window opens.

However, a more common practical compromise is to accept that one region will be in their evening. Let’s look at specific candidate slots in UTC to see how they affect the three cities during summer months.

Evaluating Specific Candidate Slots

When choosing a time, you are balancing inconvenience. Here is how three common slots affect the New York, London, and Tokyo team members during June (Summer Time).

Option 1: 13:00 UTC

Option 2: 14:00 UTC

Option 3: 15:00 UTC

Based on this analysis, 13:00 UTC or 14:00 UTC are the most viable options. They place the burden on the Asian colleague to stay up slightly later, while keeping the Americas and Europe within reasonable daytime hours. If your team includes Sydney (UTC+10 or UTC+11 depending on DST), the math shifts slightly, but the logic remains: find the hour where the "night" side is least disrupted.

Handling Daylight Saving Time Shifts

Daylight Saving Time creates complexity because regions change clocks on different dates. The US and Europe usually shift in March and October/November, while many Asian countries do not observe DST at all. This means the relative gap between cities changes twice a year.

If you use fixed offsets like "UTC-5," you will be wrong for half the year. Instead, use IANA timezone identifiers. These identifiers automatically handle the shift. For example, America/New_York knows when to switch from EST to EDT.

You can verify the current offset using JavaScript’s Intl API, which is built into modern browsers and Node.js environments. This ensures your calculations are accurate regardless of the date.

function getLocalTime(city, utcDate) {
    // Create a formatter for the specific city timezone
    const formatter = new Intl.DateTimeFormat('en-US', {
        timeZone: city,
        hour: 'numeric',
        minute: 'numeric',
        hourCycle: 'h23'
    });
    
    // Format the UTC date into the local time of the city
    return formatter.format(utcDate);
}

// Example: Check what time it is in New York when it is 13:00 UTC on June 22
const meetingTimeUTC = new Date('2026-06-22T13:00:00Z');

console.log(getLocalTime('America/New_York', meetingTimeUTC)); 
// Output: "9:00 AM"

console.log(getLocalTime('Europe/London', meetingTimeUTC)); 
// Output: "2:00 PM"

console.log(getLocalTime('Asia/Tokyo', meetingTimeUTC)); 
// Output: "10:00 PM"

This code snippet demonstrates how to programmatically determine the local time for any city given a UTC timestamp. It respects DST rules automatically, ensuring you don’t schedule a meeting at 8:00 AM when it is actually 9:00 AM due to a clock shift.

Visualizing Working Hour Overlaps

Text-based calculations can be tedious. Visual charts help identify the overlap window quickly. Imagine a horizontal axis representing 24 hours in UTC. Each team member has a colored bar representing their working hours.

For the NY/London/Tokyo example in June:

If you plot these, you see that London overlaps with both New York and Tokyo. New York and Tokyo do not overlap directly. The "sweet spot" is the hour where London is active, and the other two are on the edges of their windows. London acts as the bridge.

Tools like TimeForge visualize this by stacking these bars and highlighting the intersection. It uses color coding to show quality: green for full overlap, yellow for partial, and red for no overlap. This removes the mental math of converting time zones manually. When you add teammates by selecting their cities, the tool pulls the correct IANA data and renders the chart instantly.

Sharing the Schedule Effectively

Once you have chosen a slot, such as 13:00 UTC, sharing it clearly prevents confusion. Avoid sending just "Meet at 13:00 UTC" without context, as some recipients may not know their current offset. Avoid sending just "Meet at 9 AM EST," which is meaningless to someone in Tokyo.

The best practice is to provide the time in each participant’s local zone. You can do this manually in an email or calendar invite.

Example email snippet:

Meeting Time: Tuesday, June 22 New York: 9:00 AM EDT London: 2:00 PM BST * Tokyo: 10:00 PM JST

If you use a scheduling tool, it often generates this breakdown automatically. TimeForge, for instance, creates a shareable link. When a colleague clicks the link, they see the meeting time in their own local timezone, regardless of where they are located. This ensures everyone sees "9:00 AM" if they are in New York, and "10:00 PM" if they are in Tokyo, without needing to calculate the difference themselves.

Best Practices for Global Coordination

Scheduling is about respect for different rhythms. Here are three rules to keep meetings efficient:

  1. Keep it short: A 30-minute meeting is easier to fit into the narrow overlap window than a 60-minute one. If you need more time, consider asynchronous updates via written summaries before the call.
  2. Rotate inconvenience: If you have a team in Australia and the US, the meeting will always be early morning for one side. Rotate the times so the burden is shared over months, rather than always forcing the Asian team to be late-night.
  3. Record for non-attendees: If someone cannot make the overlap slot due to personal constraints, record the session. This allows them to catch up on their own time without disrupting the synchronous group.

For teams that struggle with manual calculation, automated tools can simplify this process. TimeForge’s slot finder ranks times based on working-hour overlaps, highlighting slots that are green for everyone. It handles the DST conversions and local time displays, letting you focus on the agenda rather than the clock.

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?

Always schedule meetings in Coordinated Universal Time (UTC) to avoid confusion caused by independent regional clock shifts. This ensures the meeting time remains consistent for all participants regardless of whether their local clocks have advanced or retreated.

Can I save my team's time zone settings?

Yes, most calendar applications allow you to save specific time zones for recurring meetings or individual contacts. Setting these preferences once ensures future invitations automatically convert to the correct local time for each attendee.

How do I share a meeting time without confusing others?

Share the time in UTC alongside the local time for the primary host, or use a link that automatically detects the recipient's time zone. This removes ambiguity and ensures everyone sees the correct hour for their specific location.

What if someone is on holiday?

Check the invitee's calendar availability before sending the invitation to ensure they are not out of office. If they are unavailable, propose a time that accommodates the remaining active participants or reschedule for when the absent member returns.

More guides