World Meeting Scheduler
Find the largest working-hours window two cities share by subtracting the time-zone offset from each side of their overlapping business day. Use it when booking a recurring call between offices in different countries.
Last updated: May 2026
Compare with similar
About this calculator
The scheduler computes the intersection of two identical-length business-day windows shifted by the time-zone difference. When both sides keep the same start/end hours, the math collapses to a clean closed form: rawOverlap = max(0, (workEnd − workStart) − |timezone1 − timezone2|), and the bookable buffer after carving out the meeting itself is max(0, rawOverlap − meetingDuration). Variables: timezone1 and timezone2 are UTC offsets in hours (fractional offsets such as India's +5:30 = 5.5 are supported); workStart and workEnd are the local business-day boundaries (24-hour decimal, e.g. 9 for 9 AM, 17.5 for 5:30 PM); meetingDuration is the meeting length in hours. The formula returns 0 whenever the absolute offset meets or exceeds the working-day width — i.e. New York (UTC−5) and Tokyo (UTC+9) at |9 − (−5)| = 14 ≥ 8 share no normal business hours. Edge cases: ignore DST gaps unless you adjust offsets seasonally (an extra hour can be gained or lost between March and November); cross-midnight windows (e.g. India ↔ US West Coast) need a 24-hour clock and a different formula because the day wraps; the calculator treats Saturday/Sunday as workdays — exclude weekends manually for the second region (US Friday is already Saturday in Sydney). Hard floors like fixed school pickup or childcare windows tighten the practical overlap further; the result is upper-bound mathematical overlap, not realistic availability.
How to use
Example 1 - New York (UTC-5) ↔ London (UTC+0), both 9-17, 1-hour meeting. tzDiff = 5. In NY local time: London's 9-17 becomes 4-12; intersect with NY 9-17 gives 9-12 = 3 hours of raw overlap. Subtract the 1-hour meeting → 2 hours of remaining buffer to choose a start time. Verify: 10 AM NY = 3 PM London, both inside business hours; 11 AM NY = 4 PM London, still fine; 12 PM NY = 5 PM London (end of day) - meeting must start by 11 AM NY. Two valid start slots → matches the 2-hour answer. Example 2 - Berlin (UTC+1) ↔ San Francisco (UTC-8), both 9-17, 1-hour meeting. tzDiff = 9. Intersect 9-17 SF with Berlin's 9-17 expressed in SF time = SF 0-8 → overlap is 0 hours. The formula correctly returns 0. Verify: 9 AM SF = 6 PM Berlin (after hours); 8 AM Berlin = 11 PM SF previous day. No normal-hours overlap exists - either party must shift before or after their normal day. Use this as a signal to rotate inconvenient meeting times fairly between offices rather than always burdening one side.
Frequently asked questions
Why does the calculator return 0 even though my colleague and I have agreed on a time?
A 0 result means there is no overlap inside the standard 9-17 (or whatever you entered) business day of both regions. You can still meet, of course - one side has to extend before or after normal hours. To model that, widen the work window on one side (e.g. set workEnd to 19 for the western party who agrees to take a late call) and the formula will return positive overlap. This is the recommended way to make the asymmetric burden visible: extending hours one-sided shows whose day is being lengthened. Rotating which side absorbs the extension between meetings keeps the imbalance equitable over time, which research on distributed-team well-being consistently flags as a retention factor.
Does the formula account for daylight saving time changes?
No - the calculator uses static UTC offsets and ignores DST entirely. This produces correct results for roughly 8 months of the year but is off by one hour in spring and autumn when one region has already changed clocks and the other has not. For example, the US shifts on the second Sunday of March, while the EU shifts the last Sunday - so there is a one-week window each March and October where the New York ↔ London offset is 4 instead of 5 hours. To stay accurate, manually adjust the UTC offset you input during these transition weeks, or check timeanddate.com for the exact offset on the date of your meeting. Recurring calendar entries created during a DST mismatch are a common source of missed meetings.
How should I handle meetings that cross midnight in one of the time zones?
When the time-zone difference plus a normal business day pushes one side past midnight (typical for India ↔ US West Coast at 12.5-13.5 hours apart), the simple subtraction in this calculator breaks down because the day wraps around. The practical workaround is to model the western team's next business day as their morning slot: an 8 AM Mumbai call lands at 6:30 PM (previous day) Pacific, which only works as a US afternoon, not as part of the next-day overlap. Many distributed teams adopt a fixed early/late slot - e.g. 8-9 AM Mumbai / 7:30-8:30 PM Pacific the day before - and accept that there is no realistic shared business window. The calculator returning 0 in these cases is the correct signal.
What are common mistakes when using a meeting scheduler like this?
The most common mistake is entering local clock hours when the underlying formula expects UTC-relative ones, or vice versa - always double-check whether you are reasoning in one team's local time consistently. Another frequent error is forgetting that Friday in one region is Saturday in another (US Friday 5 PM = Sydney Saturday 8 AM), so a Friday afternoon slot that looks fine is actually a weekend ask. People also commonly enter the wrong work window (8-18 because their personal day is long) when the team's actual norm is narrower, which inflates apparent overlap. A subtler mistake: averaging available hours ignores the quality of those hours - overlap at 7 AM for one party and 7 PM for the other is mathematically the same as midday for both, but the energy and engagement are very different. Finally, ignoring lunch breaks and core-hour blocks (childcare, school runs) gives optimistic numbers that fall apart in practice.
When should I NOT use a meeting scheduler calculator?
Skip the calculator for one-off meetings - just open a shared calendar tool like timeanddate.com/worldclock/meeting or your calendar's time-zone view and pick a slot visually. The calculator is most useful when defining a recurring policy (e.g. "we need a 30-minute weekly all-hands; how many hours of overlap exist?"), not for individual events. It is also the wrong tool when participants span three or more time zones - pairwise overlap underestimates the constraint, since you need the intersection of all three windows, which can collapse to zero even when each pair has hours of overlap. For asynchronous-by-default teams (where most decisions happen in writing), optimizing meeting overlap is a category error: design for handoff windows instead. And do not use it as the sole input for hiring decisions - "this candidate is in a hard time zone" should be weighed against the costs of forcing existing teammates to compromise repeatedly.