Skip to main content

How to Find a Meeting Time Across Time Zones (and Keep It Fair)

A practical guide to scheduling across time zones: line up working hours, spot the overlap window, dodge DST traps, and rotate the early call fairly.

Published By Li Lei
#time zones #meeting planner #remote work #distributed teams #scheduling

How to Find a Meeting Time Across Time Zones (and Keep It Fair)

The first time my team went fully distributed, I scheduled a "quick sync" by guessing. I knew London was ahead of San Francisco and Singapore was ahead of London, so I picked 9 AM my time and sent the invite. Two people joined at midnight, one joined at 5 PM eating dinner, and the actual work got done in Slack the next day. That meeting taught me the thing nobody tells you when your team spreads across continents: a good meeting time is not a number you pick, it's a window you find.

This guide walks through how I find that window now, why daylight saving time quietly breaks recurring calls, and what to do when the honest answer is that no single time works.

Start With Each Person's Working Hours, Not the Clock

The mistake almost everyone makes is thinking about time zones as a math problem. You convert one time to another, land on a number, and call it scheduled. But scheduling across a distributed team isn't one conversion, it's an intersection.

Here's the method that actually holds up: you line up each person's working hours in their own zone and look for the overlap window. Instead of asking "what time is 9 AM for me in Singapore," you draw every teammate's 9-to-6 on a shared 24-hour strip and see where the highlighted bands stack on top of each other. That stacked region is the only place a live meeting can land without dragging someone out of bed.

This is exactly what the Timezone Meeting Planner does. You add every participant by city or IANA zone, set the working hours (9 AM to 6 PM by default, draggable if your team runs 10 to 7), and the tool shades the hours where every single person is awake and on the clock. When there's an overlap, it's highlighted. When there isn't, it tells you so plainly instead of letting you keep hunting.

A Worked Example: San Francisco, London, and Singapore

Let me make this concrete with a setup I deal with often. Say you have three teammates: one in San Francisco, one in London, and one in Singapore. Everyone works a standard 9 AM to 6 PM in their own city.

Lay the three days side by side and the offsets do the damage. In summer, London runs 8 hours ahead of San Francisco, and Singapore runs another 7 hours ahead of London. So when it's 9 AM in San Francisco, it's already 5 PM in London and midnight in Singapore. Walk the clock forward and you find the squeeze: the only hour all three are at their desks is roughly 9 AM in San Francisco, which is 5 PM in London and 1 AM in Singapore.

That's not an overlap, that's a trap. The honest read is that these three cities barely touch. The closest you get to a shared slot is asking the London person to stay until early evening and the Singapore person to take a call near the edge of their day. There is no clean window where all three are comfortably inside 9-to-6. Seeing that on the timeline changes the conversation from "what time works" to "who absorbs the inconvenience, and how do we share it."

If you only needed a single conversion to sanity-check one of those hops, the Timezone Converter answers that in one shot. But for the three-way decision, you want the full overlap view, because the answer isn't a time, it's a constraint.

The Daylight Saving Time Traps Nobody Plans For

Two DST mistakes wreck more recurring meetings than any miscalculation.

The first is treating offsets as fixed all year. Beijing and New York are 12 hours apart in winter but 13 hours apart in summer, because the US observes daylight saving and China doesn't. If you memorize "12 hours" in January, your recurring call silently slides an hour off in March and nobody notices until someone's late. The fix is simple: always check the actual date of the meeting, not a number you remember.

The second trap is assuming every region inside one country shifts together. Phoenix, Arizona skips daylight saving entirely. So a New York to Phoenix call is 2 hours apart in winter and 3 hours apart in summer. A slot you locked in February drifts in spring, and the person in Phoenix is the one quietly showing up at the wrong time. The same logic bites parts of Australia, and anywhere the southern hemisphere flips its clocks opposite to the north.

The reason I stopped doing this in my head is that the planner pins the date and computes offsets live against the browser's IANA database. I switch the date to a summer day, watch whether the overlap window holds, and catch the break months before it would have hit my calendar. A New York to London call usually survives the shift because both cities change clocks together. A New York to Phoenix call does not. You only learn which is which by checking the summer date before you commit.

When There's No Good Slot, Rotate the Pain

Sometimes the math is just brutal. Beijing and San Francisco working 9-to-6 share zero common hours in winter, full stop. The closest you can manufacture is someone working at 7 AM or someone working at 10 PM. No slider drag fixes that, because the planet is round and your team is on opposite faces of it.

This is where fairness matters more than optimization. When no slot is good for everyone, rotating who takes the early or late call keeps it fair. If the only viable time is 7 AM for the West Coast and 10 PM for Asia, don't make the same person eat that hour every single week. Alternate it: the early bird this sprint is the night owl next sprint. The cost of distance doesn't disappear, but it stops landing on one person's sleep schedule forever.

A few patterns that have worked for my teams:

  • Rotate the inconvenient slot on a fixed cadence. Swap who takes the bad hour every two weeks so it's predictable, not a surprise.
  • Record and go async by default. If a meeting only exists to share information, kill the live call and post a recording plus notes. Save the painful synchronous hour for decisions that genuinely need real-time discussion.
  • Split a global all-hands into two live runs. One slot friendly to the Americas and Europe, one friendly to Asia-Pacific, with the same agenda. Two thirty-minute sessions beat one session where a third of the company is asleep.

The planner helps here too, because it makes the "no overlap" verdict explicit. Once everyone sees on screen that there is genuinely no shared 9-to-6 hour, the argument shifts from "find a better time" to "agree on a fair rotation." That's a much healthier conversation, and it's a lot shorter.

Putting It Together

Scheduling across time zones isn't about being clever with arithmetic. It's three habits: lay out each person's working hours in their own zone and look for where they overlap, check the real meeting date so daylight saving doesn't ambush a recurring slot, and when no time is comfortable for everyone, rotate the burden instead of assigning it to one person permanently.

Do that and the midnight-invite disaster I opened with stops happening. You send one invite, everyone knows why the time landed where it did, and the person taking the awkward hour knows it'll be someone else's turn next time. That last part, the visible fairness, is what actually keeps a distributed team together when the clock refuses to cooperate.


Made by Toolora · Updated 2026-06-13