A 09:00 start in Tokyo lands at midnight in London and 19:00 the previous evening in New York. Three cities, one clock each, and a window of shared waking hours that shrinks to almost nothing. The problem is not the math. The problem is that offsets drift, abbreviations lie, and recurring events rot silently twice a year.

Pick a single anchor. Convert every local time to it. Then write the result so nobody has to guess.

Why schedule across time zones always starts with UTC

UTC does not spring forward. It does not fall back. It is the same second for everyone, everywhere, and it is the only reference that stays fixed when a government in Cairo or a legislature in Brasília rewrites a DST rule with three days' notice.

Take Tokyo. Japan Standard Time runs UTC+9 year-round, no daylight saving. When a Tokyo-based organiser sets a call for 11:00 JST, that moment is 02:00 UTC. A London colleague on British Summer Time (UTC+1) sees 03:00 local. A New York colleague on Eastern Daylight Time (UTC-4) sees 22:00 the night before. The UTC timestamp is the single source of truth. Agree on that first, then let each participant convert.

Skip UTC and you are doing mental arithmetic with moving parts. One person forgets DST. Another confuses IST (India, UTC+5:30) with IST (Israel, UTC+2). The call time drifts. UTC stops that before it starts.

What are the real overlap windows when scheduling across time zones?

List each person's typical workday in UTC. Subtract the offset, not the other way around.

Tokyo at UTC+9, working 09:00 to 18:00 local, sits at 00:00 to 09:00 UTC. London in summer at UTC+1, working 09:00 to 17:00 local, occupies 08:00 to 16:00 UTC. New York in summer at UTC-4, working 09:00 to 17:00 local, fills 13:00 to 21:00 UTC.

The three-way overlap is 13:00 to 16:00 UTC. That puts Tokyo at 22:00 to 01:00, London at 14:00 to 17:00, and New York at 09:00 to 12:00. Tokyo carries the worst of it. Geography does not negotiate.

If the slot is too tight, shift one person's boundary. Ask the Tokyo participant to begin at 08:00 local, which is 23:00 UTC the day before. That buys an extra hour. Financial traders already think this way: London opens at 08:00 local, New York at 09:30 local, Tokyo at 09:00 local. The overlap hours are not theoretical to them. They are the workday.

When do DST transitions break scheduling across time zones?

Twice a year, for roughly three weeks, the usual offset differences collapse.

North America moves clocks forward on the second Sunday of March. Europe waits until the last Sunday of March. In 2026 those dates are 8 March and 29 March. Between them, London sits only 4 hours behind New York instead of the usual 5. The overlap window shifts by a full hour. Anyone who booked a recurring standup at 15:00 UTC now sees it land at 10:00 local instead of 11:00.

Autumn repeats the mess in reverse. Europe falls back on the last Sunday of October. North America falls back on the first Sunday of November. For one week in late October the gap widens again, then snaps back after 1 November.

A recurring invitation set once and forgotten will break. The fix is not clever software. The fix is a calendar reminder, set twice a year, to check every participant's IANA zone transition. Do it in early March and late October. Or use a scheduler that computes recurrence against zone rules, not against a frozen offset.

Which tools actually help when scheduling across time zones?

Pick a tool that shows multiple cities on one timeline and stores them as IANA identifiers. America/New_York, not "EST". Asia/Shanghai, not "CST". Europe/London, not "GMT".

Three-letter abbreviations are traps. "EST" means UTC-5 in North America and UTC+10 in Australia. "CST" covers UTC-6 (US central), UTC+8 (China), UTC+9:30 (Australian central), and UTC-5 (Cuba). One string, four different moments. Never use them in an invitation.

Your browser already knows your IANA zone. JavaScript's Intl.DateTimeFormat().resolvedOptions().timeZone returns it without a network call, reading from the operating system's region settings. Give that string to the scheduling tool. It is the only label that survives a DST rule change.

For manual checks, keep a short table of the offsets you encounter most often. Update it after each transition. A scrap of paper with four cities and their current UTC deltas is faster than any app.

How to write a meeting time so nobody misreads it

Order matters. Day of week, date spelled out, local time, UTC offset, and IANA zone. Always in that sequence.

Correct: "Wednesday 15 October 2026, 15:00 BST (UTC+1) / 10:00 EDT (UTC-4) / 23:00 JST (UTC+9)."

"9 AM" alone is noise. "9 AM EST" is worse: it claims a precision it does not have. "9 AM ET" is safer because ET covers both Eastern Standard and Eastern Daylight, but it still assumes a North American reader. For a global group, the UTC offset is the only part that works in every language.

Use 24-hour format. 15:00 cannot be confused with 03:00. 12:00 is noon. 00:00 is midnight. The 24-hour format is standard across most of the world outside the United States. It removes the single most common scheduling error: AM/PM inversion.

What are the most common mistakes when scheduling across time zones?

Midnight and noon trip people constantly. 12:00 AM is midnight, the start of the day. 12:00 PM is noon, the middle. If a 12-hour clock is unavoidable, write "12:00 noon" or "00:00 midnight." Better: use 24-hour time and write 12:00 and 00:00. No ambiguity survives.

Numeric dates cause the second failure. "10/9" is October 9 in the US and 10 September in most of the world. Spell the month: "9 October" or "October 9." ISO 8601 format (2026-10-09) is unambiguous for machines. For humans, the written month is safer.

The date line creates the third. A session at 02:00 UTC on Wednesday lands on Tuesday evening in New York and Wednesday morning in Tokyo. If the invitation says only "Wednesday at 10:00 AM," the New York colleague reads it as Wednesday morning local. It is not. Always include the UTC time and let each participant convert.

How to communicate times clearly to every participant

Send the invitation with UTC as the primary time. Most calendar apps convert automatically when the event's time zone is set correctly. Confirm the app uses an IANA zone, not an abbreviation.

Add one line in the body: "This meeting is at 15:00 UTC. Convert to your local time here:" followed by a link to a converter. Do not assume everyone knows their offset. Many people in zones without DST have never needed to learn it.

For recurring events, add a note about DST. Write: "This repeats weekly. During March and November, when DST transitions hit different zones on different dates, please check that the local time still matches your clock." The reminder costs nothing. A missed call costs credibility.

If you are the organiser, check your own transition dates first. When your zone changes and you do not update the event, the calendar app may shift the time incorrectly for every attendee, not just you.

Checklist for scheduling across time zones

Step What to do Why
1 Convert every local time to UTC first UTC is the only reference that stays fixed when DST rules change
2 Find the overlap window in UTC Removes offset math from the group decision
3 Check DST transition dates for each zone Offsets shift on different dates; recurring events break silently
4 Use IANA zone identifiers, never abbreviations "EST" and "CST" each point to multiple offsets
5 Write day, date, local time, UTC offset, and zone One unambiguous string for every reader
6 Use 24-hour format Eliminates AM/PM and midnight/noon confusion
7 Spell month names, not numbers Prevents date-format misinterpretation across regions
8 Add a DST note to recurring invitations Reminds participants to verify local times in March and November
9 Confirm the calendar app uses IANA zones Most do; some still fall back to ambiguous abbreviations
10 Review recurring events in early March and late October Catch offset shifts before they cause missed sessions