How to Schedule Meetings Across Time Zones Without the Back-and-Forth

The email chain starts innocently enough. “Hey team, let’s sync on the Q3 roadmap. What time works for everyone?” Within an hour, there are twelve replies, none of them agreeing on a time. Someone in Tokyo says morning. Someone in London says afternoon. Someone in San Francisco points out that the proposed time is 6am for them, and could we maybe do it later? By the time a slot is found, half a day has been spent on scheduling a one-hour meeting.

This is the hidden tax of distributed work. The meeting itself takes an hour. Finding the time for it takes longer. And the people who pay the highest cost are the ones who keep quiet about inconvenient times because they do not want to slow the process down.

There is a better way. This article covers the strategies and tools that eliminate the back-and-forth and make cross-timezone scheduling fast and fair.

The Pain of Cross-Timezone Scheduling

The core problem is that humans think in their own time zone. When you say “let’s meet at 2pm,” you mean 2pm where you are. Your brain does not automatically translate that into five or six other local times. So you propose a time, and each person on the thread has to convert it, realize it does not work, and propose an alternative. The cycle repeats until someone gives in.

Three factors make this worse.

Daylight saving time changes. The offset between New York and London is five hours in winter and four hours in summer, because the regions switch their clocks on different dates. A recurring meeting set up in January may silently shift by an hour in March, and nobody notices until someone shows up at the wrong time.

The international date line. When your team spans the Pacific, “tomorrow” for one person is “today” for another. Proposing “Friday afternoon” without specifying whose Friday leads to no-shows and confusion.

Cultural politeness. In many work cultures, it is considered rude to push back on a proposed meeting time, especially if the proposal comes from a manager or from headquarters. The result is that people attend meetings at 10pm or 6am rather than object, which erodes morale and productivity over time.

Common Mistakes

Assuming Everyone Knows Their UTC Offset

Most people cannot tell you their UTC offset, and even fewer can tell you how it changes with daylight saving time. Asking “what is your UTC offset?” in a scheduling thread usually generates wrong answers, which defeats the purpose.

Ignoring Daylight Saving Time

A meeting that works in February may not work in April, because the offset between two locations has shifted. This is especially common for teams that span the United States and Europe, which change their clocks two to three weeks apart. During that gap, the usual meeting time is off by an hour.

Scheduling Based on Headquarters Time

The most common anti-pattern is scheduling everything in the time zone of the company’s headquarters and expecting everyone else to adapt. This works for the headquarters and punishes everyone else. Over time, it creates a two-tier team: the people who attend meetings during working hours and the people who attend them during personal time.

Proposing a Single Time

“Does 3pm work?” forces everyone into a yes-or-no response. If the answer is no, you are back to square one. Proposing two or three options upfront reduces the rounds of negotiation significantly.

Best Practices for Cross-Timezone Scheduling

Define Core Overlap Hours

Every distributed team has a window where all or most members are awake and working. For a team spanning London, Dubai, and Singapore, that window might be 9am to 11am London time, which is noon to 2pm in Dubai and 5pm to 7pm in Singapore. Identify this window and reserve it for live meetings. Everything else goes asynchronous.

The overlap window is your most valuable scheduling resource. Protect it by not filling it with meetings that could be emails, and by keeping it clear of routine status updates that do not require real-time discussion.

Rotate Inconvenient Times

When no overlap window exists, or when a meeting cannot fit inside it, rotate which region takes the inconvenient slot. If the weekly all-hands is at 9am San Francisco time this month (which is midnight in Tokyo), move it to 6pm San Francisco time next month (which is 10am in Tokyo). Over a quarter, the burden is shared.

Rotation is not just fair. It is also a signal that the organization values everyone’s time equally, which matters more than most managers realize.

Use Visual Tools

A list of times in different zones is hard to parse. A visual timeline that shows each person’s working hours side by side makes the overlap obvious at a glance. You can see immediately where the gaps are and which times fall inside or outside working hours for each participant.

Visual tools also make it clear when a proposed time is unreasonable. A time that looks fine in your column may be shaded red in someone else’s, which is a more effective communication than a text reply saying “that is 11pm for me.”

Propose Multiple Options

Instead of asking “does 2pm work?”, offer two or three slots: “I am looking at Tuesday 2pm, Wednesday 10am, or Thursday 4pm, all in New York time. Which works for you?” This gives people a choice and reduces the chance that none of them work, which means fewer rounds of negotiation.

Default to Asynchronous

Not every discussion needs a meeting. A shared document with comments, a recorded video update, or a threaded Slack discussion lets people contribute during their own working hours. Reserve synchronous meetings for discussions that genuinely require real-time interaction: brainstorming, conflict resolution, and decisions that depend on rapid back-and-forth.

How to Find the Best Meeting Time

The practical approach to finding a meeting time across zones follows these steps.

1. List all participants and their time zones. Use city names, not offsets, so that daylight saving time is handled correctly.
2. Identify each person’s working hours. This is usually 9am to 6pm in their local time, but it varies. Some people start early, some work late, some have compressed schedules.
3. Find the overlap. Look for the window where all or most participants are within their working hours.
4. Propose two or three times within that window. State each time in at least two zones so that participants can verify without converting.
5. Confirm the date. If the meeting crosses the date line, state the date explicitly for each zone.

This process takes about two minutes with the right tool. Without one, it can take twenty minutes of tab-switching and mental math.

Using a Meeting Planner Tool

A meeting planner automates the steps above. You add participants by city, and it displays a timeline showing each person’s working hours and the overlap between them. You click on a time slot, and it shows the corresponding local time for every participant.

TimeKit’s meeting planner at /meeting-planner works exactly this way. You enter the cities where your team members are located, and it generates a visual timeline with working hours highlighted. You can drag across the timeline to find the overlap, and the tool shows the local time for each person at that slot. No mental math, no tab-switching, no email chains.

For teams that schedule cross-zone meetings regularly, a meeting planner removes the friction that makes scheduling feel harder than the meeting itself. It also makes unfairness visible — when you see that a proposed time is always in one person’s evening, you are more likely to rotate it.

A Simple Protocol for Your Team

If your team struggles with cross-timezone scheduling, adopt this protocol and stick with it for a month.

1. Always state meeting times in at least two zones (your own plus UTC, or your own plus the other participant’s).
2. Always propose two or three options rather than a single time.
3. Always check a visual planner before proposing times, so you can see the overlap.
4. Always rotate inconvenient times for recurring meetings.
5. Always default to asynchronous unless real-time interaction is necessary.

After a month, the back-and-forth will have dropped significantly, and the meetings that do happen will be scheduled in a fraction of the time. The tool does the conversion. The protocol does the coordination. Together, they make cross-timezone scheduling a solved problem.