Meeting Time Zone Planner — find an overlap across cities

A single wall-clock time (say 14:00 on 11 May 2026) lands on a different moment in each time zone. The planner takes a base zone plus a base date, then walks all 24 hours of that day to score how comfortable each candidate slot is for every participant.

1. Resolve each base-zone hour (00:00 through 23:00) to a single UTC instant via Intl.DateTimeFormat. That instant is unambiguous — DST shifts, half-hour offsets, and historical zone changes are all part of the IANA tz database your browser ships.
2. For every participant, format that same UTC instant in their local zone. The result is their personal clock for the slot — including the calendar date, which may be ±1 day from the base date.
3. Classify each participant's local hour against their working window. Four buckets:
   • Working — local hour falls inside [workStart, workEnd). Score +2.
   • Stretch — exactly one hour before or after the working window. Score +1.
   • Off-hours but awake — outside the working window but not asleep. Score 0.
   • Likely asleep — local hour in [22, 06). Score −2, so the planner never recommends a 03:00 call when an alternative exists.
4. Sum the participant scores for each base-zone hour. The hour with the highest total is the recommended meeting time. Ties break to the earlier hour of the day.

The same answer is checked algebraically. Each participant's working window on the base date — interpreted as their local date — is converted to a single UTC instant interval (e.g. London 09:00–17:00 on 11 May 2026 = UTC 08:00–16:00). Intersecting those intervals gives the set of UTC instants where every participant is working. Any fully working hour in the grid has to fall inside that intersection — when it does, the calculator surfaces a verified ✓badge. When the intersection is empty, there's no perfect overlap and the top slot is the best compromise instead.

Everything runs client-side. The browser ships the full IANA tz dataset, the ECMAScript Internationalization API surfaces it through formatToParts(), and the scoring is a 24 × N integer-arithmetic loop — so the page works fully offline after first load and never sends your inputs over the network.

For a scheduler sitting in Sri Lanka the arithmetic is simpler than for most of the world, because Asia/Colombo holds a fixed UTC+5:30 with no daylight saving — the offset you learn once is the offset all year. The part that moves is always the other side of the call. A London or New York counterpart jumps an hour twice a year; an Australian teammate jumps the opposite way because the southern hemisphere's summer falls in our winter. That is exactly why the grid looks up each offset at the precise meeting instant instead of caching a single number per city. Take a standing 2:30 PM Colombo call with a London client: that is 9 AM in London through the winter (GMT), but once British Summer Time starts in late March it becomes 10 AM London. A recurring invite that felt comfortable in January quietly creeps an hour if you pin it to London's wall clock rather than to Colombo's — the kind of drift the grid makes visible at a glance, and the reason a quick check before a DST changeover is worth the thirty seconds.

If you only need to read one clock against another rather than score a whole day, the time zone converter does a single point-in-time conversion, and the world clock shows several cities live side by side. To measure how many days sit between two meeting dates — useful when a recurring call drifts across a DST changeover — reach for the date difference calculator.

The cases below trace the scoring by hand so you can reproduce every line in the tool above: a clean two-city overlap, two no-overlap compromises across three continents, a day rollover, and a Gulf-plus-UK setup that plenty of Sri Lankan freelancers run with clients in Dubai and London. The math uses 11 May 2026 throughout so the daylight-saving states stay fixed and comparable.

• IANA Time Zone Database (tzdata) — canonical source for global offset and DST rules
• ECMA-402 — Intl.DateTimeFormat specification (timeZone option)
• MDN — Intl.DateTimeFormat.prototype.formatToParts()
• TC39 Temporal — ZonedDateTime disambiguation rules (informative)

Time-zone offsets and DST transitions were last cross-checked against the IANA tzdata edition shipped in current Chrome/Firefox/Safari on 2026-05-11. The data refreshes through your browser's own update cycle.