Skip to content
OmniTools

Time Zone Meeting Overlap

Find the hours two cities actually share in a working day, at the date you choose. Real DST offsets, honest no-overlap answers, and a rotation when thin.

All date & time tools

Meeting time zone overlap

Time zones (2 of 6)

The first zone you pick is the anchor: the working hours and the overlap window are shown on its clock.

Result

Waiting for today's date. Your browser will fill it in as soon as the page is interactive, or pick any date above.

Nine and a half hours apart in the northern summer and ten and a half in the winter, which is the whole problem: a 9-to-5 day rarely overlaps.

Offsets are read at the chosen date from your browser’s own time zone database, so they are correct for daylight saving without downloading anything. A meeting, though, is a fixed instant. The safest habit is to put the time in the invite in UTC as well as local, and to re-check before a recurring series that spans a transition, because the same invite resolves to a different local time for the far end once a clock moves.

This tool runs entirely in your browser. Nothing you enter is uploaded, stored, or logged.

What this tool does

Pick two to six cities, set each one's working day, and the tool reports the hours those days actually share, at the date you choose rather than at some average offset. Daylight saving is read from your own browser's time zone data for that exact instant, so there is no database here to go stale. When a pair genuinely has no shared working hours, it says so instead of manufacturing a green slot.

How it works

Offsets are read through Intl.DateTimeFormat with IANA identifiers such as Asia/Kolkata and America/New_York, at the instant you pick. That means daylight saving is whatever the browser's own data says it is on that date, including the awkward zones: India at UTC+5:30, Nepal at UTC+5:45, Yangon at UTC+6:30, Chatham at UTC+12:45, and Lord Howe Island, which shifts by only 30 minutes. There is no time zone file to download and nothing here to maintain.

The shared window is found by sweeping the anchor zone's day in 15-minute steps and keeping the longest run that falls inside every zone's working hours. The sweep runs across two days so a window straddling local midnight is found as one continuous run rather than split in half. The result is expressed on the anchor zone's clock, and every other zone then reads the same absolute window on its own.

The United States changes its clocks on the second Sunday in March and the European Union on the last, about three weeks later. For that window only the US has moved, so the New York to London gap is 5 hours instead of 4, and a Monday standup that works in April does not work on 20 March. The gap is computed from the transition instants rather than assumed, zones that keep no summer time are named separately, and the southern hemisphere, where clocks move the other way, is called out on its own.

When the shared window is under three hours, a single recurring slot means one person always takes the awkward time. The rotation plan lays out five consecutive weekly slots with the local time in each zone, crossing out the ones that fall outside someone's working day so the cost is visible rather than assumed. For New York and Tokyo there is no overlap at all on a nine-to-six day, and the honest answer there is a plan, not a green slot.

Worked example

New York and London, both on a 09:00 to 18:00 day, compared on 20 March 2026 and again on 28 September 2026.

  1. 20 March 2026: the US moved its clocks on 8 March, the EU not until 29 March, so the gap between them is 5 hours
  2. New York's 09:00 to 18:00 reads as 13:00 to 22:00 in London, and the overlap inside both working days is 09:00 to 14:00 New York time
  3. 28 September 2026: both sides are on summer time, so the gap is 4 hours
  4. The same pair, the same hours, now shares only 09:00 to 13:00 New York time

5 hours of shared working hours on 20 March and 4 hours on 28 September, an hour lost to the three-week US and EU desynchronisation.

Accuracy and limitations

  • Offsets come from your browser's own time zone database. Nothing here contacts a server, and a device carrying very old time zone data may disagree with a current one.
  • Working days are not modelled. A city with a Friday to Saturday weekend, or a public holiday, will read as available here and will not be.
  • A meeting is a fixed instant. Put the time in the invite in UTC as well as local, and re-check any recurring series that spans a clock change.

Frequently asked questions

Does it account for daylight saving?
Yes, and that is the main reason to use a date field rather than a fixed offset. The offset for each city is read at the exact instant you choose, so a slot that works in one month and fails the next is reflected in the answer instead of being averaged away.
What happens when two cities have no overlap?
The tool reports no window instead of inventing one. A 09:00 to 18:00 working day in New York and one in Tokyo genuinely share no hours at all, and a calculator that showed a green slot there would simply be wrong. You get a rotation plan instead.
Why is the New York to London gap sometimes 5 hours?
Because the US changes its clocks on the second Sunday in March and the EU on the last, about three weeks later. During that window only the US has moved, so the gap is 5 hours rather than 4 until the EU catches up on 29 March 2026.
Which cities and zones are supported?
The list covers the Indian subcontinent, the Gulf, South-East Asia, Europe, Africa, the Americas and Australia, including the awkward offsets. Any IANA identifier the browser recognises will work, including Chatham at UTC+12:45 and Lord Howe Island, whose daylight saving shift is only 30 minutes.
Our overlap is only 90 minutes. What should we do?
Rotate it. Below three hours a single recurring slot always lands on the same people, so the tool lays out five weekly slots an hour apart with the local time in every zone, and marks each one that falls outside somebody's working day so you can pick the fairest week.