When a meeting involves participants in different time zones, the first question is not which clock time to pick, but whether any overlap exists between their local working hours. The calculation starts by converting each participant's available time window into a single reference frame, usually UTC, then finding the intersection. This article gives the exact steps, the formulas, and the judgment criteria for a workable slot.
Convert Local Times to UTC Offsets
Every time zone has a fixed offset from UTC, expressed as +HH:MM or -HH:MM. For example, New York is UTC-5 during standard time and UTC-4 during daylight saving, while London is UTC+0 or UTC+1. To convert a local time to UTC, add the offset if the zone is east of UTC, and subtract if west. If the offset is negative, adding it to the local time gives the UTC equivalent.
For a meeting window, convert both the start and end of the available period. Suppose a participant is available from 09:00 to 17:00 local time in a zone with UTC+2. The UTC window is 07:00 to 15:00. For a zone with UTC-7, the same local window becomes 16:00 to 00:00 UTC the next day, which crosses a date boundary. Always write the UTC window with a date marker if the end time is less than the start time.
Overlap Calculation for Two Participants
With two UTC windows, the overlap starts at the later of the two start times and ends at the earlier of the two end times. If the overlap start is before the overlap end, a valid meeting slot exists. The length of that slot is the difference between the two. For example, participant A is available 08:00-16:00 UTC, participant B is available 10:00-18:00 UTC. The overlap is 10:00-16:00, which is six hours.
If the overlap start equals the overlap end, the meeting can only be a single instant, which is not practical. If the overlap start is after the overlap end, no overlap exists. For a meeting to be useful, the overlap length should be at least the planned duration. A 30-minute meeting needs at least 30 minutes of overlap, and a 10-minute buffer for starting and ending is common practice.
Handling Half-Hour and Quarter-Hour Offsets
Not all time zones use whole-hour offsets. India is UTC+5:30, Nepal is UTC+5:45, and some regions use UTC+8:45. When converting these zones, the minutes part of the offset must be carried through the calculation. A local time of 10:15 in UTC+5:30 becomes 04:45 UTC. The overlap calculation remains the same, but the resulting times may fall on quarter-hour or half-hour boundaries.
For scheduling, it is easier to round the overlap window to the nearest 5-minute increment, but the rounding must not extend the meeting beyond the actual overlap. If the true overlap is 10:02-12:18 UTC, the practical window is 10:05-12:15 UTC. This preserves the buffer and prevents scheduling a meeting that starts before everyone is available.
Three or More Participants
For more than two time zones, find the overlap sequentially. Start with the first two windows, get their overlap, then intersect that result with the third window. Repeat for all participants. The final overlap is the common slot for everyone. For three participants with UTC windows 07:00-15:00, 09:00-17:00, and 10:00-14:00, the first overlap is 09:00-15:00, and intersecting with the third gives 10:00-14:00.
If the common overlap is too short, narrowing the availability of one participant is an option. For example, if one person is only available for the first half of their window, check whether that sub-window produces a longer common slot. Alternatively, adjust the meeting duration. A 45-minute meeting may fit where a 60-minute meeting does not.
Standard Business Hours as a Default Filter
When participants do not specify exact availability, standard business hours serve as the default. The most common definition is 09:00-17:00 local time, but some regions use 08:00-16:00 or 10:00-18:00. Applying the same default to all participants simplifies the overlap calculation and gives a conservative result. For a meeting that must include lunch breaks, the 12:00-13:00 period is excluded from each participant's window.
For teams with flexible schedules, a wider default window such as 08:00-18:00 is used, which results in a larger overlap. The key is to define the window explicitly before the calculation. If a participant works from home and has a different start time, the default is replaced with the actual hours.
Practical Example: Three Cities
Consider a meeting with participants in New York (UTC-4), London (UTC+1), and Singapore (UTC+8). All use 09:00-17:00 local time. New York's UTC window is 13:00-21:00. London's is 08:00-16:00. Singapore's is 01:00-09:00. The overlap of New York and London is 13:00-16:00 UTC. Intersecting with Singapore gives 01:00-09:00, so the common overlap is 13:00-09:00, which is empty because the start is after the end. No overlap exists.
To find a workable slot, adjust one participant's window. If Singapore is available from 08:00 to 18:00 local, its UTC window is 00:00-10:00. The overlap with the New York-London window becomes 13:00-10:00, which is empty. If New York starts at 08:00 local, its UTC window is 12:00-20:00, and the New York-London overlap becomes 12:00-16:00 UTC. Intersecting with Singapore's 00:00-10:00 yields 12:00-10:00, which is also empty. A non-empty overlap requires a participant to work outside standard hours or a meeting time that falls outside the standard windows.
Daylight Saving Time Adjustments
Daylight saving time changes the UTC offset for many regions, but not all. When a meeting is scheduled across a DST transition date, the offset for that specific date must be used. For example, if the meeting is on the first Sunday of November in the United States, New York switches from UTC-4 to UTC-5. A meeting scheduled for 15:00 UTC on that day corresponds to 10:00 local time before the switch and 09:00 after the switch, depending on the exact hour.
The UTC offset for the meeting date is checked, not the current offset. A reliable time zone database or a converter that handles DST rules is used for this purpose. If the meeting is repeated weekly, the overlap is recalculated for each week because the offset may change mid-series.
Checklist for a Workable Meeting Slot
Before finalizing a meeting time, the following steps are taken. First, each participant's local availability window is written and converted to UTC using the correct offset for the meeting date. Second, the overlap of all windows is found. Third, the overlap length is confirmed to be at least the meeting duration plus a 5-minute buffer. Fourth, it is checked that the overlap does not include any excluded break times. Fifth, the final UTC time is converted back to each participant's local time and verified to fall within their stated window. Sixth, if no overlap exists, the participant whose window is the constraint is documented, and a time outside standard hours for that participant is noted.
For a recurring meeting, the calculation is repeated for each occurrence. A slot that works in January may fail in March because of a DST change. A table of UTC offsets for each participant and each meeting date is kept to make the schedule transparent.