How to Schedule a Meeting Across Time Zones (Without the Math)

To schedule a meeting across time zones without doing the math, work out each person's reasonable local window (roughly 8am to 9pm), look for where those windows overlap, and then collect availability with a poll that automatically shows each participant the times in their own time zone. Nobody converts anything, so nobody gets it wrong.

That last part matters more than people expect. Most cross-time-zone failures are not caused by having no shared window; they are caused by conversion mistakes: someone forgot the US changes clocks three weeks before Europe, or read "Wednesday 9pm" as their Wednesday when it was already Thursday in Sydney.

The rest of this guide covers why manual conversion keeps failing, how to think about fairness for recurring calls, the concrete NYC + London + Sydney example, which tools to use, and a step-by-step playbook. If you just want the poll, create one free: each respondent sees the grid in their own local time automatically.

Converting time zones by hand feels like simple arithmetic, and then reality intervenes:

• Daylight saving time shifts on different dates. The US and Europe do not change clocks on the same weekend, so for a few weeks each spring and autumn the usual offset is wrong by an hour. A standing "9am New York, 2pm London" call quietly becomes 1pm London during those windows, and someone shows up an hour off.
• Some places do not observe DST at all. Most of Arizona, all of India, China, and Japan, and Queensland in Australia never shift. If your mental offset was learned in winter, it can be wrong in summer.
• The date line flips the day. A Thursday morning call in Sydney is a Wednesday evening call in San Francisco. Say only "Thursday" and half the group anchors on the wrong day.
• Half-hour and 45-minute offsets exist. India is UTC+5:30 and Nepal is UTC+5:45. Anyone rounding to whole hours is wrong by construction.
• "6pm" is ambiguous. The classic thread: "does 6pm work?" followed by "wait, is that my 6pm or yours?" Every unlabeled time in a multi-zone conversation is a coin flip.

None of these are rare edge cases; a weekly global call will hit several of them per year. The reliable fix is to stop translating and let software render each person's local time, which is exactly what a time-zone-aware availability poll does.

Before proposing any time, write down a reasonable local window for each participant. A common default is roughly 8am to 9pm local time: early enough to catch mornings, late enough to allow an evening call, and outside the hours where attendance quality collapses.

Then intersect the windows. This is where distributed groups get a hard dose of reality, because the shared window shrinks fast with spread.

Take New York, London, and Sydney. London is 5 hours ahead of New York, and Sydney is 9 or 10 hours ahead of London depending on the season (the two hemispheres shift DST in opposite directions). Work through 8am-9pm local for each city and you find there is essentially no slot that is comfortable for all three. The least-bad options sit at the edges: early morning in New York is early evening in London but already past bedtime in Sydney, while Sydney's morning is New York's previous evening. Whatever you pick, at least one city is outside normal hours.

That is not a tooling failure, it is geometry, and knowing it up front changes the decision:

• Two-region calls are usually fine. US East plus Europe, or Europe plus India, have real shared windows.
• Three-region calls spanning the Americas, Europe, and Asia-Pacific usually have no fair slot. Plan to rotate (next section), split into two sessions, or move some of the work to async updates.
• Edges beat middles. The workable global slots cluster around 7-9am US East, which is early afternoon in Europe and late evening in Asia-Pacific.

For a one-off meeting, someone taking a 7am or 10pm call is a favor. For a weekly meeting, it is a policy, and parking the bad slot on the same region forever burns people out and quietly signals whose time matters least.

Better patterns:

• Rotate the slot. Alternate between two or three times so each region takes turns being inconvenienced. Week A: good for US and Europe, rough for Sydney. Week B: good for Europe and Sydney, early for the US. Publish the rotation so it feels deliberate, not accidental.
• Rotate attendance instead. Keep one time but alternate which region's optional attendees are expected live, and record for the rest.
• Split the meeting. Run the same agenda twice with the organizer attending both. More work for one person, humane for everyone else.
• Reconsider whether it needs to be a meeting. Distributed teams that write good async updates need fewer synchronous slots, which shrinks the problem.

When you set up a rotation, re-poll each block rather than assuming last quarter's answer still holds: school runs, seasons, and DST all move people's real availability. A quick poll where everyone sees their own local times makes the re-check nearly free.

Two tool families help here, and they solve different halves of the problem.

World clock planners like timeanddate.com's Meeting Planner and World Time Buddy show several cities side by side with color-coded working hours. They are excellent for the organizer's first step: seeing where windows overlap before proposing anything. Their limitation is that they do not collect anyone's answer; you still have to broadcast a time and hope, and the participants are back to interpreting zone names.

Availability polls with automatic conversion solve the collection half. You share one link, and the tool renders the grid in each respondent's own local time. Nobody converts, so nobody miscoverts.

Timespree is a free example of the second kind: each participant sees the grid in their own local time automatically, marks when they are free, and the heatmap shows the group's overlap. Respondents do not need accounts, it works properly on phones, and you can import busy times from Google Calendar, Outlook, or Apple Calendar for free while responding, which catches the conflicts people forget. For a broader look at grid tools, see our When2meet alternatives roundup; classic When2meet has only a manual time zone dropdown, which is exactly the kind of step people get wrong.

Use both: a world clock to choose a sane window to ask about, a poll to get the real answer.

Here is the full process, start to finish:

• 1. List every participant's city or time zone. Ask if you are not sure. This list drives everything else.
• 2. Check the spread with a world clock planner. Two neighboring regions: proceed normally. Three regions spanning the globe: accept now that someone will be outside normal hours, and decide how you will share that burden.
• 3. Pick a candidate window inside the overlap. Aim for roughly 8am-9pm local for everyone, using the edges (US East mornings, Europe afternoons) when the spread is wide.
• 4. Create an availability poll over that window. Keep it to one focused week. Because the poll shows each person their own local time, you do not need to explain any conversions in the invite. Start one here.
• 5. Set a response deadline and name it clearly. "Answer by Thursday" plus your zone, or simply rely on the poll's local rendering.
• 6. Send one reminder to non-responders the day before the deadline.
• 7. Book the winner as a calendar invite immediately. Calendar invites carry proper time zone data, so once it is on everyone's calendar, DST and date-line problems are handled by their calendar app.
• 8. For recurring calls, re-poll at each DST change. Twice a year, the March-April and October-November shifts silently move your meeting for part of the group. A 30-second re-check beats a month of confusion.

The whole flow takes the organizer maybe ten minutes, and no participant ever does arithmetic.

Rules of thumb for frequent combinations. Treat these as starting windows to poll over, not final answers; individual schedules still vary, which is the point of polling.