1. Scope
Finds candidate meeting slots and a fair rotation plan across participants in different time zones over a date range, and surfaces daylight-saving-time pivots. Output is informational, not a booking engine.
2. Inputs and outputs
Inputs
- participants array
Each: label, IANA time zone, and local working-hours window.
- meeting_duration_minutes number
- start_date date
- range_days number
How many days forward to search.
- slot_interval_minutes number
Granularity of the candidate-slot search.
Outputs
- candidateSlots
Time slots that fit inside every participant's working hours, scored by how central they are.
- rotationPlan
A schedule that spreads inconvenient hours fairly across participants.
- dstWarnings
Dates in the range where a DST change shifts the offsets.
Engine source: src/lib/time-zone-overlap-planner/engine.ts
3. Formula / scoring logic
for each slot in [start_date .. start_date + range_days] stepped by slot_interval_minutes:
if the slot (meeting_duration_minutes long) fits inside every participant's local working hours → candidate
4. Assumptions
- Working hours are entered in local time per participant.
- Uses the IANA time zone database via the browser's Intl API — subject to the browser's bundled TZDB version.
5. Data sources
- IANA Time Zone Database as of 2024b
6. Known limitations
- Cross-hemisphere DST offsets (e.g. US fall-back vs EU fall-back 1 week apart) can temporarily narrow or widen the overlap — the tool surfaces the warning but does not auto-reschedule.
7. Reproducibility
Input
participants = [Berlin 9–17, NYC 9–17], meeting_duration_minutes = 60, a start_date, range_days = 14, slot_interval_minutes = 30.
Expected output
Candidate slots cluster around 15:00–17:00 Berlin / 09:00–11:00 NYC (standard time); a DST warning flags the two weeks each spring/fall when the offset diverges. Exact slots vary with start_date.
8. Change log
- 2026-04-24 methodology page first published.
Worked example
Run live against the same engine this site ships
(/engines/time-zone-overlap-planner.js).
The inputs and outputs below are recomputed on every build and
independently re-verified in CI — they are never hand-authored.
Input
- tool
- timezone_overlap_planner
- meeting_duration_minutes
- 60
- start_date
- 2026-03-10
- range_days
- 7
- slot_interval_minutes
- 30
- participants[0].id
- nyc
- participants[0].name
- New York
- participants[0].time_zone
- America/New_York
- participants[0].work_start_hour
- 9
- participants[0].work_end_hour
- 17
- participants[1].id
- lon
- participants[1].name
- London
- participants[1].time_zone
- Europe/London
- participants[1].work_start_hour
- 9
- participants[1].work_end_hour
- 17
- participants[2].id
- blr
- participants[2].name
- Bangalore
- participants[2].time_zone
- Asia/Kolkata
- participants[2].work_start_hour
- 10
- participants[2].work_end_hour
- 19
Output
- warnings[0]
- No overlap windows found under current working-hour constraints.
- assumptionsEcho.participantCount
- 3
- assumptionsEcho.meetingDurationMinutes
- 60
- assumptionsEcho.startDate
- 2026-03-10
- assumptionsEcho.rangeDays
- 7
- assumptionsEcho.slotIntervalMinutes
- 30
Frequently asked questions
- What does the Time Zone Overlap Planner calculate?
- Finds candidate meeting slots and a fair rotation plan across participants in different time zones over a date range, and surfaces daylight-saving-time pivots. Output is informational, not a booking engine.
- What inputs does the Time Zone Overlap Planner need?
- It takes 5 inputs: participants, meeting_duration_minutes, start_date, range_days, slot_interval_minutes. Outputs returned: candidateSlots, rotationPlan, dstWarnings.
- What formula does the Time Zone Overlap Planner use?
- The exact computation is: for each slot in [start_date .. start_date + range_days] stepped by slot_interval_minutes:; if the slot (meeting_duration_minutes long) fits inside every participant's local working hours → candidate;
- Can I verify the Time Zone Overlap Planner with a worked example?
- Yes. With participants = [Berlin 9–17, NYC 9–17], meeting_duration_minutes = 60, a start_date, range_days = 14, slot_interval_minutes = 30. the tool returns Candidate slots cluster around 15:00–17:00 Berlin / 09:00–11:00 NYC (standard time); a DST warning flags the two weeks each spring/fall when the offset diverges. Exact slots vary with start_date.
- Where does the Time Zone Overlap Planner get its benchmark data?
- Reference data is sourced from: IANA Time Zone Database (as of 2024b).
- What can the Time Zone Overlap Planner not tell me?
- Known limitations: Cross-hemisphere DST offsets (e.g. US fall-back vs EU fall-back 1 week apart) can temporarily narrow or widen the overlap — the tool surfaces the warning but does not auto-reschedule.