How to Schedule a Meeting Across Multiple Time Zones

A project lead in New York picks 9 a.m. for a "quick sync," fires off the invite, and only later realizes half the team in Singapore is being asked to dial in at 9 p.m. Nobody converted anything wrong — 9 a.m. New York genuinely is 9 p.m. Singapore. The mistake was choosing a time before checking whether it fell inside anyone else's working day at all.

That's the part single-time converters can't help with: they translate one instant into another notation, but they don't tell you whether that instant is a reasonable hour for the other three people on the invite. This guide covers the actual scheduling method — listing working hours, finding the overlap, handling the times when no overlap exists, and getting the invite itself right. For the mechanics of translating a single time between zones, see our guide on how to convert between time zones; for the underlying units, our what is UTC guide covers that separately.

The method has three steps, and all of it is easier to do in UTC rather than juggling several local times in your head:

• Get each attendee's UTC offset. Not the abbreviation — the actual offset, since two people can both say "Eastern Time" while sitting on different sides of a daylight-saving switch.
• Convert each attendee's normal working hours into that offset. If someone works 9 a.m.–6 p.m. and their offset is UTC−5, their working day runs 14:00–23:00 UTC.
• Line the ranges up and look for the hours common to all of them. Whatever UTC range survives the overlap of every attendee's working hours is a fair meeting slot.

This is the whole trick: once every attendee's day is expressed as one shared unit — UTC — an overlap either exists as a visible block or it plainly doesn't, and you stop guessing.

Say you're scheduling a call between New York (standard offset UTC−5), London (UTC+0), and Singapore (UTC+8), and everyone's normal working day is 9 a.m. to 6 p.m. local. Converting each working day into UTC and marking it against a scan of the clock shows exactly where things line up — and where they don't.

New York and London share a clean block, 14:00–18:00 UTC — 9 a.m. to 1 p.m. in New York, 2 p.m. to 6 p.m. in London. Add Singapore and that block disappears entirely: every hour it's working hours in Singapore, both New York and London are asleep. Two-city overlaps are common; once a third distant zone joins, a genuine three-way window often doesn't exist at all, and that's not a scheduling failure — it's geography.

When the table shows no shared block, or only a sliver of one, you have a few honest options rather than one "right" answer:

• Take the least-bad edge hour. An hour at the very start or end of someone's working day (7 a.m. or 7 p.m., say) is usually easier to accept than the middle of their night.
• Split the discussion. Run two shorter overlapping sessions — one that suits region A and B, another for B and C — with the person in the middle briefing both.
• Shrink the group. Not every topic needs every time zone live; a smaller decision-making group can meet in the good window and share notes with the rest.
• Move it async. Covered in full in the last section — often the right call when no live slot is genuinely fair.

When there's no overlap and someone has to join outside normal hours, the fairness problem is usually bigger than the scheduling problem. If the same region always takes the 6 a.m. or 10 p.m. call because it's "easiest" for the person setting up the invite, that team quietly absorbs the cost of every future meeting too.

The practical fix is a rotation: alternate which region takes the early or late slot from one occurrence to the next, and say so explicitly in the recurring invite ("early slot for APAC this month, EU next"). It costs nothing to set up and it's the difference between one team feeling perpetually deprioritized and the discomfort being genuinely shared.

Two practical habits limit the damage. First, if a recurring meeting is anchored to a specific region's local time (say, "always 10 a.m. New York time"), let the calendar tool handle the shift — most will recalculate the UTC time automatically as that region's clocks change, so other attendees see a one-hour shift in their own local time rather than a broken meeting. Second, when the switch dates for different attendees' regions don't line up, double-check the invite by hand for the two or three weeks in between — that's the specific window where an automatically-shifted invite can quietly land at the wrong local hour for someone. For how daylight saving actually works and which regions observe it, see our full guide to daylight saving time.

The scheduling math only pays off if the invite itself can't be misread. A few habits make that reliable:

• Name the city, not just the abbreviation. "10:00 New York time" survives a DST switch better than "10:00 EST," which is technically wrong for half the year and easy to misapply.
• Include the UTC time somewhere in the description. It's the one reference every attendee can check against regardless of their own offset, and it's unaffected by anyone's daylight saving schedule.
• Spell out the date, not just the time. Near the international date line, a time difference can push a meeting into the next or previous calendar day for one attendee — "Tuesday 9 a.m." can mean "Wednesday" somewhere else on the call.
• Let calendar software do the per-attendee conversion. Most calendar tools display each invitee's own local time automatically once time zones are set correctly on each account — that removes an entire category of manual-conversion mistakes.

• Assuming an abbreviation is unique. CST can mean U.S. Central Time or China Standard Time, eight hours apart. Name the offset or city instead.
• Setting a recurring meeting once and never rechecking it. A meeting scheduled correctly in July can land an hour off in December if attendees' regions handle daylight saving differently.
• Converting one person's time and assuming it works for the group. Confirming the organizer's slot is fine says nothing about whether it falls inside anyone else's working day.
• Ignoring the date line. A time difference of eight or more hours can shift the meeting to a different calendar date for someone, not just a different clock time.
• Ending the invite with a bare local time and no time zone at all. Without an explicit zone, a copied or forwarded invite is a guess for anyone outside the organizer's region.

If the working-hours table keeps coming back empty, or the only overlap regularly asks someone to join before sunrise, that's useful information, not a scheduling puzzle to keep solving. A recurring status update that never has a fair live slot is usually better handled as a recorded summary, a shared written update, or a document with comments — reserving the rare live overlap for the discussions that genuinely need real-time back-and-forth.

A reasonable rule of thumb: if a live meeting requires someone to be awake outside a wide "acceptable" range (say, 7 a.m. to 9 p.m. local) more than occasionally, replace it with an async format by default and treat a live call as the exception, not the norm.