International Scheduling: A Practical Guide to Cross-Time-Zone Planning

The hard part of international scheduling is not the arithmetic. The arithmetic is solved — a decent converter will tell you that 2 PM in London is 9 AM in New York and 10 PM in Tokyo. The hard part is fairness: who has to take the call at 6 AM, or at 11 PM, and is that burden shared or always falling on the same people? Good international scheduling is a design problem, not a calculation. Here is how to think about it.

Start with the overlap window

Every distributed team has an overlap window — the hours of the day when all members are on the clock at the same time. The size of that window determines what kind of collaboration is possible:

• 4+ hours of overlap allows real-time collaboration, pair work, and live meetings.
• 2–4 hours is enough for a daily standup and a few focused meetings, but not for extended collaboration.
• Under 2 hours means you are effectively an async team, and you should design for that rather than pretending otherwise.
• Zero overlap means handoff-only workflows — one team hands work to the next, like a relay race.

Map the overlap window honestly before you schedule anything. If your team spans New York, London, and Sydney, your common overlap is roughly 8–9 AM New York / 1–2 PM London / 10–11 PM Sydney — about an hour, and only on days when Sydney is not already asleep. That is an async team with a small live window, not a synchronous team with a time-zone inconvenience.

Our Meeting Planner visualizes overlap windows across multiple zones so you can see the shared hours at a glance.

Protect the overlap window for high-value work

The overlap window is scarce. Do not fill it with status meetings that could be written down. Reserve it for the things that genuinely benefit from real-time interaction: decisions with ambiguity, brainstorming, conflict resolution, onboarding, and relationship-building. Everything else — status updates, progress reports, FYIs — belongs in writing. If you find your overlap window is consumed by standups, you are wasting the one resource that makes your team a team.

Rotate the burden

If a recurring meeting must happen at an inconvenient time for someone, rotate who bears the inconvenience. A weekly call between San Francisco and Berlin has two reasonable slots: 8 AM SF / 5 PM Berlin, or 6 PM SF / 3 PM Berlin (the latter only on days when Berlin is not already heading to bed). Alternating between them each week shares the pain. Document the rotation so it is visible, and stick to it for at least a quarter — frequent rotation is as disruptive as no rotation.

The same principle applies to on-call rotations, incident response, and customer support. If the same region always takes the overnight shift, you will burn out those people and they will quit. Rotation is not just fair; it is a retention strategy.

Write down the time zone rules

Teams that span time zones need an explicit, written set of conventions. A few questions to answer:

1. What time zone is "the team's" time? Some teams pick UTC as a neutral reference. Others pick the headquarters' time, which can subtly privilege that office. State the choice and the reasoning.
2. What does "9 AM" mean in a calendar invite? Is it 9 AM in the organizer's zone, or 9 AM in the attendee's? Most calendar tools default to the organizer's zone, which can surprise attendees. Clarify the convention.
3. How are recurring meetings handled across DST transitions? A meeting that works in February may break in March. Decide whether meetings stay at the same UTC instant (so local times shift) or the same local time (so the UTC instant shifts).
4. What is the response-time expectation across zones? If someone is off the clock, do not expect a reply. Write it down.

Design for async by default

The single best thing you can do for international scheduling is to reduce the number of meetings that need to happen in the first place. Async-first workflows — written specs, recorded demos, decision documents, comment threads — let people contribute during their own working hours without coordinating a live slot. This is not a productivity hack; it is a structural change that makes the time-zone problem smaller. We cover the mechanics in detail in Async Communication.

A useful test: for any proposed meeting, ask "could this be a document?" If yes, write the document. If no, the meeting is probably worth the scheduling cost.

Use the right tools

A few tools that genuinely help:

• A world clock you trust. Pin the zones of your teammates. Our World Clock lets you see several zones side by side, updated for DST.
• A timezone converter that reads the IANA database. Mental math is error-prone, especially around DST transitions. Our Timezone Converter handles it.
• A meeting planner that shows overlap. Visualizing the shared hours is faster than listing times and hoping people can mentally convert. Our Meeting Planner does this.
• A shared calendar with time-zone support. Google Calendar and Outlook both display invites in the viewer's local time, which is what you want. Make sure everyone knows to set their working hours in the calendar so meeting organizers can see conflicts.

Watch for DST transitions

Twice a year, in March/April and October/November, recurring international meetings break because different regions shift on different dates. The US and EU are out of sync for a few weeks each spring and autumn, which shifts the gap between New York and London by an hour. Audit your recurring meetings around those dates, and communicate any time changes explicitly — do not assume attendees will notice. For the mechanics, see Daylight Saving Time Explained.

The bottom line

International scheduling is a design problem. Map your overlap window, protect it for work that needs real-time interaction, rotate the burden of inconvenient times, write down your conventions, and default to async so you need fewer meetings in the first place. The arithmetic is the easy part; the fairness and the communication are what make a distributed team actually work.