Time Zone Meeting Planner
| Zone | Standard UTC offset | DST rule | Anchor city |
|---|---|---|---|
| America/Los_Angeles | UTC-8 | US (Mar-Nov) | Los Angeles |
| America/Denver | UTC-7 | US (Mar-Nov) | Denver |
| America/Chicago | UTC-6 | US (Mar-Nov) | Chicago |
| America/New_York | UTC-5 | US (Mar-Nov) | New York |
| America/Anchorage | UTC-9 | US (Mar-Nov) | Anchorage |
| Pacific/Honolulu | UTC-10 | none | Honolulu |
| America/Sao_Paulo | UTC-3 | southern (Oct-Feb) | Sao Paulo |
| Europe/London | UTC+0 | EU (Mar-Oct) | London |
| Europe/Paris | UTC+1 | EU (Mar-Oct) | Paris |
| Europe/Berlin | UTC+1 | EU (Mar-Oct) | Berlin |
| Europe/Moscow | UTC+3 | none | Moscow |
| Asia/Dubai | UTC+4 | none | Dubai |
| Asia/Kolkata | UTC+5:30 | none | Mumbai |
| Asia/Shanghai | UTC+8 | none | Shanghai |
| Asia/Tokyo | UTC+9 | none | Tokyo |
| Australia/Sydney | UTC+10 | southern (Oct-Apr) | Sydney |
| Pacific/Auckland | UTC+12 | southern (Sep-Apr) | Auckland |
Distributed teams do not have a meeting problem, they have an overlap problem - and the honest version of it is measured in the other city's local clock. Pick your zone, a partner, a third wheel, and your working hours: the scanner walks the next 24 hours in 15-minute steps and reports the longest stretch where all three desks are inside the window, with every local time printed side by side. It reads each zone through the browser's IANA time-zone database, so daylight-saving transitions are handled per-zone and per-rule rather than by a hardcoded offset.
The reference table shows why some pairs are doomed to asynchronous work: standard offsets from UTC-10 (Honolulu) to UTC+12 (Auckland) leave Los Angeles and Tokyo with essentially no 9-to-5 intersection - a 15-minute handoff at somebody's evening is the realistic maximum, and knowing that beats pretending otherwise.
How to use
- Choose your zone, two colleagues' zones, and the workday window you all share (default 8 to 17).
- The result is the longest common window in the next 24 hours, printed in everyone's local time - share it as-is in the calendar invite.
- If the scan returns nothing, widen the window or accept an async handoff: the table's DST column shows which zones jump on different dates, quietly changing every fixed-time meeting twice a year.
Frequently asked questions
How does the planner handle daylight saving time?
Live lookups go through the browser's IANA tz database (Intl.DateTimeFormat), which encodes each zone's own DST history and rules - US zones shift in March and November, EU zones on different March/October dates, southern-hemisphere zones in the opposite season, and several zones never shift at all. Two fixed-UTC-offset meetings per year silently become wrong when that is ignored; scanning live local time is the honest method, and the DST dates table lists the exact transition dates to avoid scheduling across.
Why can't Los Angeles and Tokyo find a 9-to-5 overlap?
The zones sit 17 hours apart on standard time - Tokyo's workday start is Los Angeles's midday previous-day afternoon already spent. There is no hour that is 9-to-5 in both, so the practical pattern is a boundary handoff: end-of-day Los Angeles meets start-of-day Tokyo (about 4-6 PM PT / 9-11 AM JST), or the reverse handoff 12 hours later. The scanner will confirm the tiny window or rule it out, which is itself useful information.
Should a distributed team just standardize on UTC?
Partially. UTC works as the canonical storage format - log timestamps, calendar entries, and status pages should all be UTC so nothing is ambiguous - but humans do not live in UTC: a team spread from Vancouver to Auckland spans 20 hours, and calling everything UTC just hides the pain in someone's 3 AM. The workable pattern is UTC for records plus the overlap scanner for the human meetings, keeping standing calls inside whatever honest window exists and rotating who takes the edge.
Why do some zones have 30- or 45-minute offsets?
Political history, not geography: India runs UTC+5:30, Nepal UTC+5:45, and parts of Australia UTC+9:30, each a legacy of pre-standardization local mean times kept for cultural or administrative convenience. The planner handles them natively through the IANA database, but they matter for overlap math - a Mumbai colleague is 30 minutes off every neighboring zone's assumption, which has ended more than one recurring call.