# How to schedule meetings across time zones

*August 10, 2026 · Charles Brun · Playbook · Everest Blog*

> Across time zones someone always pays for the meeting. This is how to work out who, how often, and how to stop paying for meetings you did not need.

Most advice about scheduling across time zones is a converter with extra steps. Find the overlap,
be explicit about the zone, use a tool. All true, all useless the moment your team spans more than
one hop.

The thing the advice leaves out is that across time zones a meeting is not free. Someone eats
breakfast during it, or misses bedtime for it, or joins from a car. The only real questions are who
pays, how often, and whether the meeting was worth anyone paying for at all.

That reframing changes what you do. You stop hunting for a slot that works for everybody — often
there isn't one — and start deciding, deliberately, how to distribute a cost you cannot remove.

## Start from the overlap, not from the invitation

The instinct is to propose a time and let people counter. Do it the other way round: work out the
shape of the overlap first, once, and let it constrain everything after.

Take three cities, each working a civilised nine to six.

<figure class="post-figure">
<img src="/static/blog/overlap-window.png" alt="A band chart of working hours in San Francisco, London and Bengaluru plotted on one 24-hour UTC axis. London and Bengaluru share three and a half hours; London and San Francisco share one hour; there is no hour that falls inside working hours in all three cities.">
<figcaption>Nine to six in three places, on one axis. Two pairs overlap. All three never do.</figcaption>
</figure>

London and Bengaluru share three and a half hours. London and San Francisco share one. San
Francisco and Bengaluru share nothing at all — the Californian day begins as the Indian day ends.

This is the ordinary case, not a pathological one. Add a third hop to any pair and the common window
tends to collapse to zero. Once you have seen that picture, the question "when shall we all meet?"
stops being a scheduling problem and becomes a design problem, and the honest answers are: meet in
pairs, meet asynchronously, or decide who is going to be uncomfortable.

Work this out once per pair of locations and write it down. It is a property of where your people
live, not of any particular week, and it only changes when someone moves or the clocks do.

## When the overlap is empty

Three options, in the order I would try them.

**Split the meeting.** Two pairwise conversations at humane hours usually beat one call where a
third of the room is asleep. You lose the shared moment; you gain two people who can think.

**Make it asynchronous.** A written brief with a deadline for comments does the work of most
status meetings, and it does it in everyone's own working day. This is the option people skip
because it feels slower — and then hold a 6 a.m. call to read a document aloud.

**Pick who pays, explicitly.** Sometimes the meeting genuinely has to happen live, with everyone
present. Then say so, name the person carrying the cost, and treat it as a cost rather than a
rounding error: "This one is 7 a.m. for Maya. We are doing it because the contract closes Friday."

The failure mode is not choosing. An unstated default is still a default, and it is nearly always
"the most junior or most distant person joins at a terrible hour, indefinitely."

## Rotate the cost on anything recurring

A one-off bad slot is a favour. The same bad slot every Tuesday for a year is a policy, and it is
the one that quietly drives people out of distributed teams.

For any standing meeting that crosses an empty overlap, alternate. Weeks one and three suit
Bengaluru; weeks two and four suit San Francisco. Nobody enjoys it, everybody sees it is even, and
the fairness is visible in the calendar rather than asserted in a handbook.

Two details make rotation stick:

- **Put the rotation in the event title.** `Ops sync (SF-friendly week)` tells a newcomer more than
  any wiki page, and it survives the person who set it up leaving.
- **Anchor each variant to a city.** A rotating meeting that drifts with daylight saving stops being
  fair the moment the clocks move — and they do not move on the same date in every country.

## Make the zone visible before you propose

Everything above assumes you can see the other zone while you look at your week. If you are still
converting in your head, you will keep proposing slots that look reasonable and land at 9 p.m.

Two zones beside the grid removes the arithmetic for the relationship you deal with most; a world
clock covers the rest; and events anchored to a city stay correct when you travel. The mechanics —
which setting, where, and what each one is actually for — are in
[how to show multiple time zones in Google Calendar](/blog/google-calendar-multiple-time-zones/).

The point is not the feature. It is that a zone you can see is a constraint you will respect, and a
zone you have to calculate is one you will get wrong on a busy afternoon.

## Write invitations that survive travel and daylight saving

Most cross-zone scheduling failures are not conversion errors at the moment of booking. They are
drift: an invite that was right in March and wrong in April.

- **Anchor the event to the city it belongs to**, not to wherever you happened to be sitting when
  you created it. A recurring call tied to New York follows New York's clock changes; one tied to
  your laptop follows you on holiday.
- **Put the zone in the title for anything that matters.** `Board prep (09:00 CET)` costs nothing
  and settles every argument at a glance.
- **Expect the clocks to move on different dates.** The US, Europe and the southern hemisphere do
  not switch together, so there are stretches of the year when a transatlantic meeting is an hour
  off from what both parties assumed — about four weeks of 2026, for New York and London. The
  mechanism, and how to pin a series against it, is in
  [why your recurring meeting drifts an hour twice a year](/blog/recurring-meeting-daylight-saving-drift/).
- **Re-check standing meetings twice a year.** Put a fifteen-minute review in the calendar for the
  weeks after each transition. It is the cheapest bug fix in scheduling.

## Apply the async test before you book anything

Before you spend anyone's morning, ask what the meeting is actually for. Three honest categories:

| What it is for | Does it need everyone live? |
| --- | --- |
| Sharing information — status, updates, read-outs | No. Write it. Meetings are the most expensive way to distribute text |
| Making a decision with people who disagree | Usually yes, but only the people who actually disagree |
| Building trust — new hires, hard conversations, repair | Yes, and worth an uncomfortable hour |

The middle row is where the discipline lives. A decision meeting needs the people with a position,
not the department. Cutting the invite list is often what turns an impossible slot into an easy one:
three people across two zones can nearly always find an hour, while nine people across four cannot.

If you are choosing which of your own hours to give up for the ones that survive this test, the
trade-off between focused work and coordination is the subject of
[maker's schedule vs. manager's schedule](/blog/makers-schedule-vs-managers-schedule/).

## A default policy, in five lines

Most teams do not need a philosophy. They need five defaults that stop the argument recurring:

1. **Core hours.** Name the window where live conversation is allowed at all — for a London–Bengaluru
   team, 09:00–12:30 UTC. Outside it, async is the default. How to derive that window, and what the
   research says about the cost of getting it wrong, is in
   [core hours for a distributed team](/blog/core-hours-distributed-team/).
2. **Quiet hours.** Name the hours that are nobody's to book, and mean it.
3. **Rotation.** Any recurring meeting crossing an empty overlap alternates, and says so in its title.
4. **Anchoring.** Every recurring event is tied to a city, and reviewed after each clock change.
5. **The async default.** Information-sharing goes in writing. Meetings are for disagreement and
   for people.

Five lines in a shared doc will outperform any tool, because the tool cannot decide who pays. Once
the defaults exist, the weekly work is just placing them — which is a
[weekly planning](/blog/weekly-planning-calendar-guide/) problem, not a time zone one.

## Where an assistant fits

The mechanical part of all this — checking two calendars, proposing three slots that respect both
sets of working hours, sending the invite in the right zone, re-proposing when someone counters — is
work that does not need you.

That is the part Everest takes. You CC `everest@everest.ag` on the thread, and it negotiates against
your real availability across every calendar you have connected, in the zones the participants
actually live in, until there is an invite. It will not decide whether a 7 a.m. call is worth it.
That judgement stays yours, and it is the only part of this that was ever interesting.

What you are left with is a smaller, better question than the one you started with: not "what time
works for everyone", which across enough distance has no answer, but "is this worth someone's
morning, and whose turn is it?"

---

Published at https://everest.ag/blog/schedule-meetings-across-time-zones/ · Everest is an AI scheduling assistant — CC it on any email thread and it books the meeting across every calendar you run. Learn more at https://everest.ag/