· Updated May 7, 2026 · TimeZoneMeet editorial team
Cross-time-zone scheduling fails in two predictable ways. The first is a quiet math error: someone subtracts hours by hand, gets the wrong offset, and only notices once an attendee misses the call. The second is a labelling error: "9am Tuesday" goes into the invite without a time zone, and the recipient assumes their own clock. Each individual mistake is small, but the cumulative cost across a globally distributed team — missed handoffs, doubled-up rescheduling, calls that start at 5am for one engineer — is large enough that most teams quietly tolerate the friction rather than fix it.
This guide walks through a small set of habits that prevent almost all of those failures. None of them require a heavyweight calendar tool. They work whether you use Google Calendar, Outlook, Notion calendar, a shared spreadsheet, or pen and paper. They are also boring, which is the point: scheduling across time zones is one of those tasks where novelty causes more problems than it solves.
Start with the overlap, not the slot
The first habit is to find the overlap window before you propose a specific time. List every required attendee with their city. Convert each city to a working-hours band — say, 9am–6pm in their local time. The overlap of those bands is the only honest space in which a fair meeting can sit. If the overlap is two hours wide, you have two hours to choose from. If it's zero, you cannot hold a synchronous meeting fairly, and the right answer is async.
A worked example: San Francisco (America/Los_Angeles), Berlin (Europe/Berlin), and Bangalore (Asia/Kolkata). At standard offsets in May, when SF is at UTC−7, Berlin is at UTC+2, and Bangalore is at UTC+5:30. The Bangalore working window of 9:00–18:00 IST translates to 03:30–12:30 UTC. Berlin's 9:00–18:00 is 07:00–16:00 UTC. SF's is 16:00–01:00 UTC. The three windows overlap exactly between 16:00 and 16:30 UTC — a 30-minute slice. Translated back to wall clocks, that is 09:00–09:30 in San Francisco, 18:00–18:30 in Berlin, 21:30–22:00 in Bangalore. There is no fair 60-minute slot that respects everyone's stated working hours; one region must absorb the shift, or the meeting must be split.
The Schedule tool on TimeZoneMeet does this overlap calculation directly between any two cities, ranks the candidate windows by how cleanly they fit both sides' preferred hours, and surfaces "compromise" slots when no clean overlap exists. For three or more participants, the simplest reliable approach is to run pairwise checks between the two hardest-to-reconcile cities first, then verify the chosen window against the third.
Write every time with an explicit zone
The second habit is to never put a time on the wire — in an invite, a chat message, an email, or a doc — without a time zone tag. "Tuesday at 9" is ambiguous and will be misread by at least one recipient. The robust formats are:
- Two zones with abbreviations, when both sides know the abbreviations: "Tuesday May 12 at 09:00 PT / 12:00 ET". Use this when communicating only within North America, where PT/ET/CT/MT are unambiguous.
- UTC anchor, when teams span continents: "Tuesday May 12 at 17:00 UTC". UTC is unambiguous, never observes DST, and is what calendar software stores under the hood. Most calendar UIs let you display times in UTC alongside local time.
- Named city plus a converter link, when one region is the centre of gravity: "Tuesday May 12 at 09:00 in San Francisco (your local time will display in the calendar invite)". This works because modern calendar tools store the meeting in the organizer's zone and convert on display.
What you should not use, ever, is an unqualified abbreviation like EST, CST, or IST across regions. EST in North America means UTC−5; in Australia, the same letters mean UTC+10. IST is Indian Standard Time (UTC+5:30) for one audience and Irish Standard Time (UTC+1) for another. CST can be Central Standard Time in the US (UTC−6) or China Standard Time (UTC+8). We have a longer write-up on this in why time zone abbreviations are ambiguous; the short version is to prefer either the city name or the IANA zone identifier.
Re-check around DST transitions
The third habit is to put a calendar reminder on the four DST transition dates that affect your team and re-verify any recurring meeting that crosses regions. The 2026 transitions to be aware of, for most teams:
- March 8, 2026 — United States and Canada spring forward.
- March 29, 2026 — most of Europe springs forward.
- October 25, 2026 — most of Europe falls back.
- November 1, 2026 — United States and Canada fall back.
The three weeks between the US transition and the European transition are when recurring US ↔ Europe meetings drift by an hour. A standup that is normally 09:00 PT / 18:00 CET in winter will, between March 8 and March 29, become 09:00 PT / 17:00 CET — because the US has lost an hour relative to Europe but Europe has not yet shifted to compensate. Calendar invites stored in the organizer's local time absorb this automatically, but invites stored in UTC do not. If your calendar tool is storing in UTC, you will see the meeting move on the recipient's calendar, which is sometimes desirable and sometimes catastrophic. The way to avoid surprise is to know which storage your calendar uses and verify a recurring series before each transition. Our deeper post on DST and meeting planning covers the failure modes for each major calendar tool.
India, China, Japan, most of Africa, and most of South America do not observe DST. If your team includes Bangalore, Shanghai, or Tokyo, those cities sit at a fixed offset to UTC year-round, and any "drift" you see comes from the other side. That is sometimes counter-intuitive: when the US loses an hour in March, the gap between San Francisco and Bangalore shrinks by an hour, even though nothing has changed in India.
Use a fair-hours band for both endpoints
The fourth habit is to define a "reasonable hours" band — for example, 06:00 to 21:00 local — and to enforce it on both the start and the end of the meeting, for every required attendee. A slot that starts at 20:30 in someone's local time and runs sixty minutes ends at 21:30, outside the band. This is the single most common subtle mistake in distributed scheduling: the start time looks acceptable, but the meeting overruns the working day on the back end. The TimeZoneMeet Schedule tool checks both endpoints by default and flags slots that violate the band.
For a deeper treatment of why the back-end check matters and how to negotiate the band itself, see how to avoid 5am calls.
Rotate the pain when it can't be avoided
Some teams genuinely have no overlap. A San Francisco–Bangalore standup at a fair hour for both sides is essentially impossible: every overlap is at the edge of someone's working day. When you have to hold the meeting anyway, rotate the inconvenience. If this week's slot is 21:00 IST / 08:30 PT (late evening for India), next week's should be 07:00 IST / 18:30 PT (early morning for India, end of day for the US). Document the rotation in the meeting description so it is visible to anyone who joins later. Our rotation guide walks through three rotation patterns we have seen work in practice.
Verification checklist before you send the invite
- Confirm each participant's current local time with a lookup, not from memory. Offsets change with DST, and your mental model is probably six months out of date.
- Re-state the meeting time in at least two formats — typically a UTC anchor plus one named region — in the invite description.
- Check both the start time and the end time against everyone's reasonable-hours band.
- If a participant is travelling or recently relocated, ask which time zone they would like the invite to use; do not assume their calendar reflects the right zone.
- For recurring meetings, set a reminder to re-verify the next instance after each DST transition that affects any required attendee.