Understanding cross-timezone scheduling
One instant, many local clocks.
What a "time zone" actually is, why daylight saving makes naive maths wrong, and why the grid shows when overlap really exists.
A timezone is a function, not an offset.
The intuition that "London is GMT" and "New York is GMT-5" is roughly right twice a year. Both cities observe daylight saving on different schedules — London's clocks shift on the last Sunday of March and October; New York's on the second Sunday of March and first Sunday of November. For about three weeks of every year the gap between London and New York is four hours, not five. The right mental model is: a timezone is a function that takes a date and returns an offset — not an offset itself.
offset = tz(date)
UTC is the only universal clock.
Underneath every local time is a single global instant called UTC (Coordinated Universal Time). UTC has no daylight saving, never shifts, and is the only clock that can be compared across cities without ambiguity. Every conversation about overlapping times is really a conversation about the same UTC instant projected into each participant's local clock. Compute in UTC, render in local — that's the entire model.
IANA names beat fixed offsets.
The right way to identify a participant's timezone is by IANA name — "America/New_York", "Europe/London", "Asia/Tokyo" — not by a fixed offset like UTC-5 or BST. The IANA database knows every daylight-saving rule, every historical change, every political shift in observation. Pick a city; the system handles the offset for whatever date the meeting is. Storing UTC-5 in your database means you'll be wrong about scheduling for half the calendar year and entirely wrong for any meeting that happens to span a DST transition.
A worked overlap.
Three colleagues in London, New York and Tokyo want to meet for an hour. London works 09:00–17:00 local; New York 09:00–17:00 local; Tokyo 09:00–17:00 local. Project all three windows onto the UTC axis: London = UTC 09:00–17:00 (winter), New York = UTC 14:00–22:00 (winter), Tokyo = UTC 00:00–08:00. The intersection of all three is empty — there's no UTC instant where all three are in business hours. The closest overlap is 14:00–17:00 UTC (London/New York only). Tokyo would have to take an early or late slot.
Three-way overlap, winter
9–17 local in London (UTC+0), New York (UTC-5), Tokyo (UTC+9)
Project each window onto UTC, intersect, count the overlap hours.
LON: 09–17 ; NYC: 14–22 ; TYO: 00–08 (UTC)
= ∅ — no all-three overlap
Two-way overlap
London + New York
Two windows shifted by 5 hours.
LON ∩ NYC = 14–17 UTC = 14–17 LON / 09–12 NYC
= 3 hours
The DST "skipped hour" trap.
When clocks spring forward, an hour simply doesn't exist in the local timezone — 02:00 to 03:00 just isn't there on that calendar day. Scheduling a meeting nominally at "2:30 on March 10th in London" is undefined behaviour. Calendar systems handle this differently — some round forward, some throw an error, some silently shift. The opposite happens in autumn: 02:00 to 03:00 happens twice on the day clocks fall back. Any meeting scheduled in those windows needs a UTC anchor to be unambiguous.
Time-zone-aware date arithmetic.
"Add 7 days to this meeting" is ambiguous: does the local time stay constant (a Monday 09:00 stays a Monday 09:00, even if the DST offset shifted in between)? Or does the UTC instant stay constant (a Monday 09:00 becomes a Monday 10:00 across the DST boundary)? Both answers are defensible; calendar apps tend to choose the first because that's what users expect for recurring meetings. Database operations tend to default to the second because they store UTC and compute deltas in seconds. Knowing which mode your stack is using is the most common source of "this meeting shifted by an hour" bug reports.
What the grid is showing.
The grid here projects everyone's selected meeting window onto a single UTC axis, then renders each participant's row in their own local clock. A column is "good" only if every participant's row in that column falls inside their meeting hours. The duration slider controls how many consecutive good columns we're looking for. The host's timezone anchors the rendering so the resulting suggestion is presented in the host's local clock — what they'd actually put on the invite.
Practical scheduling rules of thumb.
For two-timezone meetings, any time of day usually works for at least one of the parties. For three-timezone meetings, the overlap window typically shrinks to one or two hours; pick days that span the most overlap. For four-or-more, the only realistic option is either a rotating "one person sacrifices their evening each week" schedule or an async-by-default cadence. Once meetings start happening at 6 a.m. for any participant, attendance and decision quality both decline.