How to schedule a meeting across time zones
Scheduling across time zones fails in four predictable ways: polling weekdays instead of dates, ignoring a daylight saving shift inside the range, treating availability as willingness, and letting one region absorb every inconvenient slot. This guide covers the method that avoids each, plus how to find a fair overlap window when no comfortable time exists for everyone.
The hard part of cross-zone scheduling is not arithmetic. Every tool converts correctly. The hard part is that a slot which is technically free for all nine people can still be a bad meeting, and nothing in a standard availability grid tells you that.
Why does converting the time not solve it?
Because free and willing are different states. At 6:30am someone's calendar is empty, so every tool marks them available. They will join, they will be half awake, and they will resent the meeting. Availability data cannot see that, which is why cross-zone scheduling needs a step that ordinary same-city scheduling does not.
- Continents is roughly where a single comfortable slot stops existing
- 3Continents is roughly where a single comfortable slot stops existing
- Daylight saving shifts a year, on different dates by region
- 2xDaylight saving shifts a year, on different dates by region
- A typical usable overlap between London and San Francisco is closer to two
- 8hA typical usable overlap between London and San Francisco is closer to two
Step one: poll specific dates, never weekdays
This is the single highest-value rule and it is the one most often broken. A poll for every Tuesday at 3pm has no fixed UTC offset. Tuesday 3pm means one absolute moment for London and a different relationship to Sydney's Tuesday, and if a daylight saving shift lands between two Tuesdays, the meeting silently moves for half the group.
Specific calendar dates are unambiguous. Tuesday 14 October at 15:00 London is one moment in time everywhere on earth. This is also why When2Meet's days-of-the-week mode is its documented weak spot for time zones while its specific-dates mode is fine.
Step two: check for a daylight saving boundary in your range
The United States, Europe and Australia change clocks on different dates, and the southern hemisphere moves the opposite direction. For roughly three weeks each spring and autumn, the offset between London and New York is one hour different from what everyone assumes.
If your date range crosses a shift, either move the range to one side of it or state the anchor explicitly in the poll description: this meeting is 15:00 London time, whatever that converts to for you.
Step three: define the overlap window before you poll
Do not poll a full day and hope. Work out the window first, because the arithmetic determines whether a fair meeting is even possible, and it is better to know that before twelve people fill in a grid.
| Pairing | Usable overlap | Practical implication |
|---|---|---|
| London and New York | Roughly 14:00 to 18:00 London | Comfortable. Most days work |
| London and San Francisco | Roughly 17:00 to 18:00 London | Tight. One side gives up an early morning or a late evening |
| New York and Sydney | Almost none in working hours | Someone takes an evening or an early morning, so rotate it |
| London, New York and Singapore | Roughly 09:00 to 10:00 London | One narrow hour. Protect it and do not waste it |
Once you know the window, set it as the poll's daily hours. Slots outside it never get generated, so nobody can accidentally vote for a time that will hurt someone.
Step four: ask about preference, not just availability
This is the step that separates a good cross-zone meeting from a technically valid one. Give people a way to say a slot works but is not welcome. In Meetly that is the preferred state, which weighs above merely free when slots get ranked, so a time three people actively want beats a time nine people merely tolerate.
If your tool has no preference concept, approximate it: ask people to mark only genuinely comfortable hours as available, and handle the edge cases in conversation.
Step five: rotate the inconvenience on anything recurring
For a one-off, pick the least bad slot and move on. For a standing meeting, the same region should not absorb the cost every week. Alternate between two slots, one favouring each side, or accept that one meeting a month happens at an awkward hour for the people who usually get the good one.
The team that always dials in at 7am is the team that quietly stops contributing to that meeting.
What is the full checklist?
List the zones, not the people
Nine people in four zones is a four-way problem. Group them first and the shape of the constraint becomes obvious.
Compute the overlap window
Find the hours inside everyone's working day. If it is empty, decide now who absorbs the cost rather than discovering it later.
Poll specific dates inside that window
Never weekdays. Never a full 24 hours.
Check for a daylight saving shift in the range
If one falls inside, move the range or state the anchor zone explicitly.
Collect preference alongside availability
Let people distinguish a slot they want from one they can merely survive.
Confirm with a calendar invite, not a message
An invite carries the absolute time and lands correctly in every attendee's calendar. A message saying 3pm starts the confusion over again.
Which tools handle this properly?
The deciding feature is whether a poll is anchored to a real date rather than a weekday, and whether it can read availability across organizations. Meetly anchors each poll to the organizer's time zone, renders it in each viewer's local time, and imports Google, Outlook, Apple and .ics calendars, so a cross-company group all contributes real busy time. It is free, with no per month fee.
The common complaint about native calendar tools is the same in both ecosystems: Google Calendar's Find a Time and Outlook Scheduling Poll both read free/busy only inside your own domain or tenant, so they degrade precisely when a meeting spans organizations. When2Meet is workable but its documented weakness is days-of-the-week mode. The full ranking is in scheduling tools for teams across time zones.
What is the best time to schedule a meeting across time zones?
The overlap of everyone's working day, which you should compute before polling rather than discover afterwards. For London and the US east coast that is usually early afternoon London time. For pairings spanning more than about ten hours, no comfortable slot exists and the decision becomes who absorbs the inconvenience.
Should I poll days of the week or specific dates?
Specific dates, always. A weekday has no fixed UTC offset, so conversions become ambiguous and daylight saving shifts move the meeting silently for part of the group.
How do I handle daylight saving when scheduling?
Check whether a shift falls inside your date range. Europe, North America and Australia change on different dates, and the southern hemisphere moves the opposite way. If a shift is inside the range, either avoid it or state the anchor time zone explicitly.
Which tools handle time zones best?
Any tool anchoring a poll to a real date rather than a weekday. Meetly anchors each poll to the organizer's time zone and renders it in each participant's local time. Native calendar tools handle conversion well but cannot read availability outside your own organization.
How do I find a time when nobody has an overlap?
Accept that someone is meeting outside working hours and decide who, deliberately, rather than letting the poll decide by accident. Then rotate it if the meeting recurs, and keep it short.
Poll across zones without the arithmetic
Set a working window once. Everyone sees their own local time, and connected calendars fill the grid.
Create a poll