Quick answer: To find a meeting time that works across time zones, convert everyone's working hours to a single reference zone (usually UTC or the organizer's), find the window where those hours overlap, and pick a slot inside it - rotating the inconvenience if no clean overlap exists. The two things that wreck this are Daylight Saving Time (which shifts offsets a few weeks a year) and simply doing the math in your head. This guide walks through the whole process, from the mental model to the edge cases.

Do it visually in seconds: Open BestSyncTime, add every participant's city, and drag the Overlap Dial to see the shared window instantly - DST and half-hour offsets handled automatically.

The core problem, stated plainly

Scheduling one meeting in one city is trivial: pick a time everyone's awake. Scheduling across time zones is hard for one reason - "a good time" is different for each person, and those windows may barely overlap. A 10 AM slot that's perfect in New York is 3 PM in London (fine), 8 PM in Dubai (borderline), and 11 PM in Singapore (unacceptable). The more zones you add, the smaller the shared "everyone's awake and working" window becomes, until for truly global teams it can shrink to zero.

Everything below is about finding that window efficiently, and about what to do when it doesn't exist.

Step 1: Establish each person's working hours

Before you can find overlap, you need to know what you're overlapping. For each participant, note their normal working window in *their own* local time - say 9 AM to 6 PM. Don't assume everyone works the same hours; some regions start earlier, and individuals may have hard constraints (school runs, caregiving) that narrow their availability further than the standard workday.

The output of this step is a simple list: person, city, and available local hours.

Step 2: Convert everyone to one reference zone

This is the step people try to shortcut and get wrong. Pick a single reference zone - UTC is the cleanest choice because it never changes for DST, though the organizer's zone works too - and translate each person's local working hours into it.

If London (currently UTC+1 in summer) works 9 AM-6 PM local, that's 8 AM-5 PM UTC. If New York (UTC−4 in summer) works 9 AM-6 PM local, that's 1 PM-10 PM UTC. Lay them all on the same UTC ruler and the overlap becomes visible: in this pair, 1 PM-5 PM UTC is when both are working - which is 2 PM-6 PM London and 9 AM-1 PM New York.

Doing this by hand for two people is manageable. For five, it's error-prone, especially with half-hour offsets (India at UTC+5:30) or during a DST transition. This is precisely the arithmetic worth delegating to a tool.

Step 3: Find the overlap window

With everyone on the same ruler, the overlap is just the span where all their converted hours intersect. Three outcomes are possible:

  • - Comfortable overlap (several shared hours): easy - pick any slot inside it, ideally mid-window so no one's at the very edge of their day.
  • - Narrow overlap (one hour or less): workable but tight. Protect it - don't let this single viable slot get eaten by other meetings.
  • - No overlap (common for US-Asia or US-Australia pairings): someone has to meet outside their normal hours. This is where fairness comes in.

Step 4: When there's no overlap, distribute the pain fairly

For teams spread across more than about eight hours, a "golden hour" where everyone is comfortably awake may simply not exist. The wrong move is to always default to the organizer's or headquarters' convenience, which quietly forces the same people to take every call at dawn or midnight. That breeds resentment and burnout - the "timezone tax" that distributed teams pay unevenly.

The fairer approaches:

  • - Rotate the inconvenience. Alternate meeting times so the early/late burden moves around the team rather than always landing on the same region.
  • - Split into sub-groups. Sometimes two smaller regional meetings plus an async summary beats one call nobody can attend comfortably.
  • - Go async by default. For many updates, a written thread or recorded video removes the need for a synchronous slot entirely.

Step 5: Account for Daylight Saving Time

Even a perfect overlap can break twice a year. Because regions change clocks on different weekends, the offset between two cities shifts for a week or three each spring and autumn. A recurring meeting anchored to one person's local time silently moves an hour for everyone else during those windows.

Two defenses: attach a specific time zone to every recurring event (so your calendar resolves it correctly at each occurrence), and re-confirm cross-border meetings around the transition dates. If you work US-Europe, the 2026 danger windows are March 8-29 and October 25-November 1.

A converter removes this whole class of error: during a transition week, check your pair in BestSyncTime before your first call - it already knows who's switched clocks and who hasn't.

The practical toolkit

Beyond the five steps, a few habits make cross-zone scheduling reliably painless:

Always name the zone. "Let's meet at 3 PM ET" is unambiguous; "let's meet at 3" is a coin flip. Put the zone on every proposed time, in writing.

Use UTC for anything critical. Product launches, incident calls, and cross-company events benefit from a single UTC anchor that no DST change can move.

Add a second clock to your devices. Phones, laptops, and Slack all let you display a colleague's local time. Seeing "it's 11 PM for them" at a glance prevents a lot of thoughtless scheduling.

Send calendar invites, not just times. A proper invite carries the time zone metadata, so each recipient's calendar shows the correct local time and adjusts automatically through DST changes.

Respect the "waking hour." Just because a slot is technically inside someone's workday doesn't mean it's humane. A 7 AM or 7 PM call is a favor you're asking, not a default you're entitled to.

Async: the option that sidesteps the whole problem

The most reliable way to solve a scheduling conflict is to not need the meeting. A large share of recurring syncs - status updates, information sharing, non-urgent decisions - can be handled asynchronously: a written update in a shared doc or channel, or a short recorded video that people watch on their own schedule.

Reserving synchronous meetings for the things that genuinely need real-time discussion (brainstorming, sensitive conversations, fast decisions) shrinks the number of hard-to-schedule calls dramatically. For a team spread across many zones, "async by default, sync by exception" isn't a compromise - it's often the better operating model outright.

Common pitfalls to avoid

  • - Assuming a fixed offset year-round. Offsets change with DST; "London is always 5 hours ahead of New York" is only true part of the year.
  • - Trusting time zone abbreviations. IST means three different things (India, Ireland, Israel); CST means three more. Use UTC offsets or full zone names.
  • - Forgetting the date line and hemisphere flip. Meetings with Australia/New Zealand can land on a different *calendar day*, and their DST runs opposite to the north.
  • - Doing mental math under pressure. The single most common cause of a missed cross-zone meeting is a hurried, wrong subtraction. Delegate it.

Putting it all together

Cross-zone scheduling comes down to a repeatable routine: capture each person's working hours, convert everyone to one reference zone, find the overlap, and - when there's no clean overlap - distribute the inconvenience fairly rather than always sparing the same people. Layer in DST awareness and a default toward async, and the twice-a-year chaos and the "wait, what time is that for me?" churn largely disappear.

The math itself is the easy part to get wrong and the easy part to automate. Handle the human judgment - fairness, humane hours, sync vs. async - yourself, and let a converter handle the arithmetic.

Find everyone's overlap now: Open BestSyncTime, add every participant, and drag the Overlap Dial to see the shared window at a glance - no math, no missed calls.