Time Zone Meeting Overlap Calculator

Team preset:

Choose a starting roster for common remote-team corridors.

Participant roster:

Format each line as Name | Time zone | HH:MM | HH:MM | weight.

Planning date:

Use a real meeting week to catch daylight-saving offsets correctly.

Reference timezone:

Pick the scheduler's timezone or a neutral UTC view.

Meeting length:

Use 15-480 minutes; longer sessions narrow the shared start window.

minutes

Scan window:

Use one day for a specific date or a workweek when you can move the meeting.

Recommendation mode:

Strict-first keeps normal hours ahead of fallback slots.

{{ err }}

Candidate step:

Use 15 minutes for precise scheduling or 60 minutes for high-level scans.

Edge-hours buffer: {{ edge_buffer }} min

Use 0 for strict teams, or up to 180 minutes for occasional early/late calls.

Workday rule:

Weekday-only uses each participant's local Monday-Friday calendar.

Minimum fallback score:

Raise this when fallback rows should stay close to working hours.

Export label:

Use a project, team, client, or meeting name.

Calendar title:

Leave the default when the export label already names the meeting.

Calendar location:

Use a room name, conference link, or leave the default video-call note.

Rank	Reference start	UTC start	Meeting end	Score	Planning note	Copy
{{ row.rank }}	{{ row.referenceStart }}	{{ row.utcStart }}	{{ row.referenceEnd }}	{{ row.score }}	{{ row.note }}

Participant	Timezone	Local meeting	Work window	Fit	Local note	Copy
{{ row.name }}	{{ row.zoneLabel }}	{{ row.localMeeting }}	{{ row.workWindow }}	{{ row.fit }}	{{ row.note }}

{{ calendarIcsText }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Global meeting time is a moving target because civil time is local, political, and date-dependent. New York, London, Singapore, Sydney, and other cities do not stay at fixed offsets from one another all year. Daylight-saving changes can shift the workable overlap by an hour even when every participant keeps the same local workday.

A useful meeting window must satisfy the full meeting length, not just a start time. A 60 minute call that begins at 16:30 local time does not fit a 09:00 to 17:00 work window, because it ends at 17:30. That distinction becomes more important as meeting length grows or when one participant has a narrower workday.

Three local work windows aligned to a 24 hour reference rail with a shared meeting window highlighted.

IANA time zone names such as America/New_York and Asia/Singapore carry more information than abbreviations such as EST or CST. They let a date-aware calculation apply the right offset and daylight-saving rule for the selected day. Abbreviations are ambiguous and often do not identify a real scheduling location.

Fair scheduling also needs a policy for imperfect options. Some teams accept occasional early or late calls, while others need strict local work-hour overlap. A weighted roster can give a critical participant more influence, but that should be used carefully. A high weighted score can still hide a bad local time for a lower-weight participant.

Calendar handoff adds one more boundary. A recommended slot can be exported as text or an iCalendar event, but people still need to confirm holidays, actual availability, meeting rooms, travel, and local business norms outside the time-zone calculation.

How to Use This Tool:

Build a roster with real IANA zones, choose the date range, then compare strict and fallback meeting windows.

Select a Team preset or use Custom roster. Each participant line must use Name | Time zone | HH:MM | HH:MM | weight.
Use IANA names in Participant roster, such as Europe/London or Australia/Sydney. Add at least two valid participant lines. The first 10 lines are scanned.
Set Planning date and Reference timezone. The scan starts from that date in the reference zone, then converts each candidate into participant-local time.
Choose Meeting length and Scan window. Longer meetings and shorter scan windows reduce the number of possible starts.
Select Recommendation mode. Strict work-hours only lists only starts that fit every work window. Strict first, then fallback uses fallback rows only when strict overlap is absent. Least-pain ranking ranks qualifying fallback rows directly.
Open Advanced to set Candidate step, Edge-hours buffer, Workday rule, Minimum fallback score, and calendar export labels.
If validation errors appear, fix unsupported time zones, invalid HH:MM values, missing roster fields, or an invalid planning date before reading Best Windows.

Interpreting Results:

Best Windows lists ranked starts in the reference zone, UTC, and a score. A strict row means every participant remains inside local work hours for the whole meeting. A fallback row means at least one participant is in edge hours or outside the normal window, but the row still meets the current score filter.

Participant Impact is the trust check. Read the local meeting time, work window, fit, and note for the best-ranked slot before sending an invite. The summary score is weighted, so it can look acceptable even when a specific participant has an early or late local time.

Overlap Heatmap shows the first scanned reference date by hour. Use it to understand why a roster has little or no strict overlap.
Calendar Invite uses the best-ranked slot. Confirm the participant impact table before copying the summary, downloading the .ics file, or opening Google Calendar.
No qualifying window means the current mode and minimum fallback score filtered out every candidate. Try a wider scan, shorter meeting, larger edge buffer, or lower score threshold.
Time-zone math does not know holidays, leave, calendar conflicts, or personal preferences beyond the roster work windows.

Technical Details:

The scan converts reference-zone calendar days into candidate UTC start times at the selected step, then evaluates every participant against that UTC interval. Local start and end are calculated in each participant's time zone for the selected date, so daylight-saving transitions are reflected by the runtime time-zone data.

A candidate is strict only when every participant is on a permitted local workday and the full meeting fits between that participant's local start and end time. Edge candidates allow starts just outside the work window when the edge-hours buffer is greater than 0. Weekend rows score 0 when the workday rule is local Monday to Friday only.

Rule Core

For one participant, early and late minutes measure how far the meeting falls outside the local work window:

painMinutes = earlyMinutes + lateMinutes

Strict participant scores are 100. Edge-hour scores start below strict rows and drop as pain grows within the buffer. Other workday scores are lower and fall as pain grows beyond the buffer. The meeting score is a participant-weighted average:

weightedScore = \frac{\sum_{i = 1}^{n} {score}_{i} {weight}_{i}}{\sum_{i = 1}^{n} {weight}_{i}}

Meeting overlap selection modes
Mode	Candidate set	Selection behavior
Strict work-hours only	Rows where every participant is inside local work hours.	Returns strict starts only.
Strict first, then fallback	Strict rows when any exist; otherwise rows meeting the minimum fallback score.	Keeps normal hours ahead of compromises.
Least-pain ranking	Rows meeting the minimum fallback score.	Ranks by weighted fit, then worst local pain, then start time.

Roster and scan limits for meeting overlap calculation
Setting	Accepted range or format	Why it matters
Roster line	`Name \| IANA zone \| HH:MM \| HH:MM \| weight`	Defines local work windows and participant weighting.
Meeting length	15 to 480 minutes	The whole interval must fit the evaluated local window.
Candidate step	15, 30, or 60 minutes	Controls how densely the day is scanned.
Edge-hours buffer	0 to 180 minutes	Allows fallback rows just before or after local work hours.
Weight	0.25 to 3	Changes how strongly a participant affects the weighted score.

Calendar output uses UTC start and end times for the generated event. The .ics text follows the iCalendar event pattern with a start, end, summary, location, and description, while the Google Calendar handoff pre-fills the same best-ranked slot in a browser tab.

Worked Examples:

US, Europe, and Asia product call

A roster with New York, London, and Singapore on normal work hours may have only a narrow shared window. With a 60 minute meeting and 30 minute step, Best Windows can show a strict row when all local times stay inside work hours. Participant Impact confirms the exact local start and finish for each city.

Long meeting removes the overlap

The same roster may support a 30 minute call but fail for a 180 minute workshop. If No qualifying window appears, reduce Meeting length, scan more days, or allow a controlled Edge-hours buffer.

Unsupported time-zone abbreviation

A line such as Berlin client | CET | 09:00 | 18:00 | 1 fails validation because CET is not the IANA location name expected by the roster parser. Change it to Europe/Berlin, then rerun the scan.

FAQ:

Why should I use IANA time zone names?

IANA names identify a location-based rule set, such as America/New_York. Abbreviations such as EST or CST are ambiguous and do not reliably carry daylight-saving behavior.

Why does the best time change when I change the date?

Offsets can change with daylight-saving rules. The Planning date determines which local offsets are used for each participant's IANA zone.

What does a fallback score mean?

It is a weighted fit score from 0 to 100. Strict work-hour rows score 100. Edge and outside-work rows lose points based on early or late minutes and participant weight.

Why are only some roster lines scanned?

The roster parser scans the first 10 nonblank participant lines in this draft. If more are pasted, the tool adds a warning so the roster can be split or simplified.

Does the calendar invite check everyone's availability?

No. The invite uses the best-ranked overlap slot and local-time summary. It does not read calendars, holidays, meeting rooms, leave, or personal conflicts.

Glossary:

IANA time zone: A location-based time-zone identifier such as Europe/London or Asia/Tokyo.
Reference timezone: The scheduler-facing zone used to scan dates and label the main result rows.
Strict overlap: A meeting start where every participant stays inside local work hours for the full meeting.
Edge-hours buffer: Allowed time just before or after a work window for fallback ranking.
Weighted score: The average participant fit score after applying roster weights.
iCalendar: A calendar data format used for downloadable event files.

References:

Time Zone Database, Internet Assigned Numbers Authority, 2026b release, April 22, 2026.
Intl.DateTimeFormat constructor, MDN Web Docs.
RFC 5545: Internet Calendaring and Scheduling Core Object Specification, RFC Editor, September 2009.