How to schedule across time zones without getting it wrong
The hard part of international scheduling is not the offset. It is that the offset moves — four times a year between hemispheres, and by legislation whenever a government feels like it.
Everyone learns the offset for the places they work with. London is five hours ahead of New York; Sydney is nine ahead of London. Both of those statements are true for part of the year and wrong for the rest, and the weeks in which they are wrong are precisely the weeks when a recurring meeting quietly moves without anyone changing it.
A time zone is not a number
The distinction that fixes most scheduling errors is between an offset and a zone.
An offset is a number: UTC+1, UTC−05:00. It describes where a clock stands at one particular moment. A zone is a rule — a named region with a history and a future of offset changes, identified by a string such as `America/New_York` or `Australia/Sydney`. The zone tells you what the offset will be on any given date; the offset alone tells you nothing about any other date.
This is why storing “UTC+1” for a colleague in Paris is a bug, and storing `Europe/Paris` is not. It is also why every operating system ships a copy of the IANA time zone database, the community-maintained reference that encodes those rules. That database is updated several times a year — countries change their DST rules, split zones, or abolish the practice entirely, and each change ships as a new release. If your software's copy is stale, your times are wrong.
Daylight saving, and the weeks when the gap changes
Roughly a third of the world observes daylight saving, and those that do switch on different dates:
- United States and Canada — forward on the second Sunday in March, back on the first Sunday in November.
- European Union and United Kingdom — forward on the last Sunday in March, back on the last Sunday in October.
- Australia (the states that observe it) — forward on the first Sunday in October, back on the first Sunday in April. Queensland, the Northern Territory and Western Australia do not observe it at all.
- Most of Asia and Africa, India, China, Japan and most of South America — no daylight saving. A constant offset year-round.
Notice what those dates do. The US springs forward two to three weeks before Europe, so for that fortnight the New York–London gap is four hours rather than the usual five. In autumn, Europe falls back a week before the US, producing another window at four hours. A weekly call scheduled at 09:00 New York time lands at 13:00 London for most of the year and at 14:00 for about three weeks of it — and nobody changed the invitation.
Between hemispheres the effect is doubled. London and Sydney are nine hours apart in the northern summer and eleven in the northern winter, with two brief transitional periods of ten. Within the United States, Arizona (outside the Navajo Nation) and Hawaii sit out the change, so Phoenix aligns with Los Angeles in summer and with Denver in winter.
The date is the error people miss
Across the Pacific the mistake is rarely an hour — it is a day. When it is 22:00 Monday in New York it is already 11:00 Tuesday in Tokyo. Someone proposing “Monday at 10pm my time” to a Tokyo colleague is proposing Tuesday, and the meeting gets booked on the wrong day about as often as it gets booked on the wrong hour.
This is the argument for always displaying the local date alongside the local time, which is what the city cards in our time zone converter do. It is also the argument for writing invitations with the weekday spelled out for every participant's zone, rather than only your own.
A method that works
- Pick an anchor zone — usually where most participants are, or where the person who cannot move their schedule sits. Everything else is expressed relative to it.
- Write out each participant's working window in their own local time. The usable band is normally 09:00–18:00; be honest about whether you can push someone to 08:00 or 19:00, and treat anything outside that as a genuine imposition rather than a rounding error.
- Look for the overlap. With two zones fewer than eight hours apart there is usually a comfortable window. Beyond about nine hours the overlap disappears and someone is taking the call early or late — decide who, and rotate it if the meeting recurs.
- Check the date at every location before you send anything, especially if the slot is near either end of the day.
- Send the invitation as a calendar event, not as text. A properly formed event carries the zone rule and converts itself for each recipient; a line of text saying “3pm GMT” does not, and will be wrong six months later.
- Diarise the transition weeks. For any recurring cross-hemisphere meeting, put a reminder in March and October to confirm the time still works.
The three-zone problem
Two zones are easy. Three are usually solvable. Four across a full spread of longitudes generally is not, and pretending otherwise produces a meeting that nobody attends properly.
New York, London and Dubai share a real window: 09:00–10:00 in New York is 14:00–15:00 in London and 17:00–18:00 in Dubai — tight, but inside everyone's day. Add Tokyo and the overlap vanishes entirely; there is no hour at which all four are within business hours, and no amount of rearranging will produce one.
When that happens the honest options are: split into two regional meetings, rotate an inconvenient slot so the same people are not always the ones taking it at 06:00, or drop the meeting and write it down instead. A recorded briefing with a written summary reaches all four zones at a reasonable hour and is, more often than not, the better artefact anyway.
Practical conventions worth adopting
- Write UTC offsets, not zone abbreviations. “CST” means Central Standard Time in North America, China Standard Time in Asia and Cuba Standard Time in the Caribbean. “UTC−06:00” means one thing.
- Use the 24-hour clock in anything crossing a border. It removes an entire class of am/pm error.
- Include the weekday — “Tue 14 Oct, 09:00 UTC−04:00”. If the weekday and the date disagree for a recipient, they will notice.
- Store zone identifiers, never offsets, in anything you build. `Europe/Paris`, not `+01:00`.
- Schedule against UTC for automated jobs, and be aware that a cron job set in a DST-observing local zone will either run twice or not at all on transition days.
None of this is difficult. It is simply a set of habits that treat time zones as rules rather than numbers — which is what they are.