How to use
Compare local times across global teams and find meeting windows that best fit everyone’s selected working hours.
Choose a date first, select the reference location, then enter duration and work preferences. Search the bundled city list or enter a supported IANA zone. Add optional participant labels and up to 12 locations.
Review Best Overall, Earlier and Later options, or select a row in the grid. Copy the selected meeting time, or use Print / Save PDF for the options and complete grid. Reset returns to New York, London and Berlin with a blank required date and 30-minute duration.
Why meeting date matters
A time zone maps UTC instants to local civil dates and clock times. The mapping may change by date. Choose the actual meeting date rather than relying on a generic fixed offset. The calculator requires a real date between 2000 and 2100; this is a software bound, not a time-zone rule.
How time-zone conversion works
Every candidate is one UTC instant. Intl.DateTimeFormat converts that instant independently into each participant’s explicitly selected zone. Meeting end equals start plus duration in elapsed minutes. The engine never uses the server’s local zone, geolocation, a longitude estimate or a network time-zone API.
IANA time zones
IANA identifiers such as America/New_York, Europe/London and Asia/Singapore name civil-time rule sets. The local city dataset stores explicit identifiers, country/region labels and search aliases. Ambiguous cities show their region, including both Springfield, Illinois and Springfield, Massachusetts. UTC offsets are secondary date-specific display details, never the authoritative location identity.
Daylight-saving time
Daylight-saving transitions can create 23-hour or 25-hour reference days. The grid covers all actual instants: missing local times are skipped and repeated local times have distinct UTC instants and offset labels. There are 92, 96 or 100 quarter-hour rows on typical 23, 24 or 25-hour days. Other offset changes, such as a 30-minute change, can produce other counts.
Working hours stay local wall-clock preferences. Both occurrences of a repeated working time are included, and missing minutes do not exist. A work interval is split if the clock moves through times outside the selected window; a meeting must fit one continuous interval. On a transition shift, the fairness midpoint and half-window use the actual elapsed duration of that continuous interval.
Reference location
The selected calendar date belongs to the reference location, which defaults to the first participant. “October 14” alone is ambiguous for a global team: a participant in Asia may already be on October 15 while someone in America is still on October 14. Switching the reference location regenerates the entire candidate day.
Working hours
09:00–17:00 is an editable convenience default, not universal business hours. Use shared hours or each participant’s individual start/end. Overnight 22:00–06:00 spans the following local day. Equal start/end is rejected instead of implying 24-hour availability. Preferences apply regardless of weekday; no public holidays are inferred.
PREFERRED means the entire meeting fits inside one entered work interval. OUTSIDE WORK HOURS means at least some elapsed meeting time does not fit. There is no EDGE buffer or separate personal-time toggle in V1. Outside-hours options remain visible and their participant fairness score is zero.
Meeting duration
Choose 15, 30, 45, 60, 90 or 120 minutes, or enter any whole duration from 5 to 480 minutes. Duration is elapsed time: 60 minutes always means 60 real minutes even if the local clock jumps. A 16:30 start fits 09:00–17:00 for 30 minutes, but not for 60 minutes. A start on the reference date may end on the next day.
Finding overlap
Candidate starts use a separate 15, 30 or 60 minute local reference grid. Rank by most participants whose full meeting fits, then highest mean fairness score, then earliest UTC instant within the reference day. When all fit, the result says ALL LOCATIONS WITHIN WORK HOURS. Otherwise it reports the best available coverage without hiding the remaining outside-hours participants.
Earlier and Later are the highest-ranked starts at least one grid interval before or after Best Overall. Missing alternatives are omitted. Coverage is evaluated only at the selected grid starts; a narrower overlap between those starts may not appear. The grid is a semantic table with text statuses and its own horizontal scroll on small screens.
How the fairness score works
Fairness measures how close the meeting is to the middle of each participant’s selected working hours. Meetings outside a participant’s work hours receive zero for that participant.
Participant score = 100 × max(0, 1 − |meeting midpoint − work-window midpoint| / half work-window duration), only when the full meeting fits. Otherwise score = 0. Team fairness = the arithmetic mean across every participant. Scores are rounded for display only; ranking uses the raw score. There are no hidden weights. Coverage takes precedence over fairness.
The 0–100 work-hours fairness score measures your entered scheduling preferences. It does not prove human or social fairness, infer preferences, or define universal protected hours.
Previous/next-day meetings
A candidate’s local start and end can fall on the previous or next date relative to the reference date. Cards and copied text include clear dates for every participant; grid cells show date badges whenever the local start differs from the reference date or the end crosses midnight. Overnight work-window checks use the relevant local shift and the whole elapsed meeting.
Recurring meetings and DST
V1 evaluates one date. It does not book meetings or rotate inconvenience across recurring dates. Recheck each future occurrence: different countries can change DST on different dates, changing a recurring meeting’s local times. A future recurring global meeting rotator would need a separate model across all selected dates.
Worked examples
These fixed-date examples are generated by the same conversion, duration-fit and ranking engine used by the grid and copy output.
New York, London and Berlin — October 14, 2026
Oct 14, 2026 · 30 elapsed minutes · 15-minute grid.
Reference: New York — New York, United States (America/New_York) — Oct 14, 2026, 09:00 UTC−04:00
UTC: 2026-10-14T13:00:00.000Z → 2026-10-14T13:30:00.000Z
Work-hours coverage: 3/3
Work-hours fairness score: 39.6/100
New York — New York, United States [America/New_York]: Oct 14, 2026, 09:00 UTC−04:00 → Oct 14, 2026, 09:30 UTC−04:00; PREFERRED; work hours 09:00–17:00
London — United Kingdom [Europe/London]: Oct 14, 2026, 14:00 UTC+01:00 → Oct 14, 2026, 14:30 UTC+01:00; PREFERRED; work hours 09:00–17:00
Berlin — Germany [Europe/Berlin]: Oct 14, 2026, 15:00 UTC+02:00 → Oct 14, 2026, 15:30 UTC+02:00; PREFERRED; work hours 09:00–17:00
Add Dubai and Singapore — October 14, 2026
Oct 14, 2026 · 30 elapsed minutes · 15-minute grid.
Reference: New York — New York, United States (America/New_York) — Oct 14, 2026, 04:30 UTC−04:00
UTC: 2026-10-14T08:30:00.000Z → 2026-10-14T09:00:00.000Z
Work-hours coverage: 4/5
Work-hours fairness score: 32.5/100
New York — New York, United States [America/New_York]: Oct 14, 2026, 04:30 UTC−04:00 → Oct 14, 2026, 05:00 UTC−04:00; OUTSIDE WORK HOURS; work hours 09:00–17:00
London — United Kingdom [Europe/London]: Oct 14, 2026, 09:30 UTC+01:00 → Oct 14, 2026, 10:00 UTC+01:00; PREFERRED; work hours 09:00–17:00
Berlin — Germany [Europe/Berlin]: Oct 14, 2026, 10:30 UTC+02:00 → Oct 14, 2026, 11:00 UTC+02:00; PREFERRED; work hours 09:00–17:00
Dubai — United Arab Emirates [Asia/Dubai]: Oct 14, 2026, 12:30 UTC+04:00 → Oct 14, 2026, 13:00 UTC+04:00; PREFERRED; work hours 09:00–17:00
Singapore — Singapore [Asia/Singapore]: Oct 14, 2026, 16:30 UTC+08:00 → Oct 14, 2026, 17:00 UTC+08:00; PREFERRED; work hours 09:00–17:00
Individual work preferences
Oct 14, 2026 · 30 elapsed minutes · 15-minute grid.
Reference: New York — New York, United States (America/New_York) — Oct 14, 2026, 09:00 UTC−04:00
UTC: 2026-10-14T13:00:00.000Z → 2026-10-14T13:30:00.000Z
Work-hours coverage: 3/3
Work-hours fairness score: 39.6/100
New York — New York, United States [America/New_York]: Oct 14, 2026, 09:00 UTC−04:00 → Oct 14, 2026, 09:30 UTC−04:00; PREFERRED; work hours 09:00–17:00
London — United Kingdom [Europe/London]: Oct 14, 2026, 14:00 UTC+01:00 → Oct 14, 2026, 14:30 UTC+01:00; PREFERRED; work hours 08:00–16:00
Berlin — Germany [Europe/Berlin]: Oct 14, 2026, 15:00 UTC+02:00 → Oct 14, 2026, 15:30 UTC+02:00; PREFERRED; work hours 10:00–18:00
A next-day crossing: Los Angeles and Tokyo
Oct 14, 2026 · 30 elapsed minutes · 15-minute grid.
Reference: Los Angeles — California, United States (America/Los_Angeles) — Oct 14, 2026, 03:15 UTC−07:00
UTC: 2026-10-14T10:15:00.000Z → 2026-10-14T10:45:00.000Z
Work-hours coverage: 1/2
Work-hours fairness score: 50.0/100
Los Angeles — California, United States [America/Los_Angeles]: Oct 14, 2026, 03:15 UTC−07:00 → Oct 14, 2026, 03:45 UTC−07:00; OUTSIDE WORK HOURS; work hours 16:00–23:00
Tokyo — Japan [Asia/Tokyo]: Oct 14, 2026, 19:15 UTC+09:00 → Oct 14, 2026, 19:45 UTC+09:00; PREFERRED; work hours 16:00–23:00
US/Europe DST mismatch — March 18, 2026
Mar 18, 2026 · 30 elapsed minutes · 15-minute grid.
Reference: New York — New York, United States (America/New_York) — Mar 18, 2026, 09:00 UTC−04:00
UTC: 2026-03-18T13:00:00.000Z → 2026-03-18T13:30:00.000Z
Work-hours coverage: 3/3
Work-hours fairness score: 56.3/100
New York — New York, United States [America/New_York]: Mar 18, 2026, 09:00 UTC−04:00 → Mar 18, 2026, 09:30 UTC−04:00; PREFERRED; work hours 09:00–17:00
London — United Kingdom [Europe/London]: Mar 18, 2026, 13:00 UTC+00:00 → Mar 18, 2026, 13:30 UTC+00:00; PREFERRED; work hours 09:00–17:00
Berlin — Germany [Europe/Berlin]: Mar 18, 2026, 14:00 UTC+01:00 → Mar 18, 2026, 14:30 UTC+01:00; PREFERRED; work hours 09:00–17:00
Assumptions and limitations
Time-zone rules come from the runtime’s IANA time-zone data and can change when governments update civil-time rules.
Browser and server runtime data can differ in update age. Government changes and far-future rules may change results; verify important meetings against updated local civil-time information. No static DST tables or current-time ranking are used. JavaScript time does not represent leap seconds; this planner compares ordinary civil scheduling minutes, not precision timekeeping.
The curated city list is not a global geocoder. Valid custom IANA identifiers are supported even without a city entry. Invalid active inputs remove all recommendations and the grid. Labels remain plain text in page memory; there are no saved teams, browser storage, URL meeting data, input analytics payloads or geolocation requests.
FAQ
How do I find the best meeting time across time zones?
Select the meeting date and reference location, add participants, and enter their working hours. The calculator ranks candidate starts by full-meeting work-hours coverage, then work-hours fairness, then earliest instant on the reference date.
Why do I need to choose a meeting date?
Civil-time offsets depend on the date. Daylight-saving rules and government changes can make the same local clock time map to different UTC instants on different dates. The chosen date belongs to your selected reference location.
Does this calculator account for daylight-saving time?
Yes. It uses Intl.DateTimeFormat with IANA zone identifiers and the runtime’s time-zone data. Missing spring-forward times are absent; repeated fall-back times appear as distinct UTC instants with their different offsets.
What is an IANA time zone?
An identifier such as America/New_York or Europe/London refers to date-dependent civil-time rules in the IANA time-zone database. It is more useful than storing a fixed offset such as UTC−05:00 for future scheduling.
How are working hours used?
Each participant uses shared or individual local wall-clock work hours. The entire elapsed meeting must fit inside a continuous work interval. Overnight shifts are supported; equal start and end times are rejected. Weekends and holidays are not automatically excluded.
How does meeting duration affect availability?
Duration is real elapsed time, from 5 to 480 minutes. A 30-minute meeting at 16:30 fits a work window ending 17:00; a 60-minute meeting at the same start does not. A local end time may cross midnight or a DST change.
How is the fairness score calculated?
For each participant whose whole meeting fits, score = 100 × max(0, 1 − midpoint distance / half work-window duration). Outside-hours participants score zero. The team score is the arithmetic mean. It measures the chosen work-hour preferences, not objective social fairness.
What happens if no meeting fits everyone’s work hours?
The calculator says no candidate on the reference date fits all selected working hours. It still shows the best available coverage and fairness, with explicit outside-hours statuses. Earlier and later alternatives follow the same ranking.
Why can a meeting fall on a different date for another participant?
A single instant can belong to different local calendar dates around the world. Every location is converted independently and receives a clear date in meeting cards and copied text, with a date badge in the grid when needed.
Does this calculator schedule or book meetings automatically?
No. It compares times locally and provides text to copy or browser print/save PDF. It has no accounts, calendar integrations, invitations, saved teams or recurring rotation. Recheck each future date because DST can change the overlap.
Sources
References describe civil-time rules and platform terminology. They do not endorse this calculator.