When are two cities both awake?
The overlap window, computed to the minute — including the half-hour zones and the daylight-saving edges that whole-hour arithmetic quietly gets wrong.
The short answer
Take each city's waking hours in its own local time, convert both to a common reference, and look at where they intersect.
With an 08:00–22:00 waking window on each side, London and New York share about 7.5 hours. New York and Mumbai share about 3. London and Sydney share about 5, and all of it sits at the extreme ends of both days.
Real windows for common pairs
Computed from the IANA database for the current date. These shift by an hour when either side changes its clocks.
| Pair | Local window, first city | Local window, second city | Shared |
|---|---|---|---|
| New York ↔ London | 09:31–16:59 | 14:31–21:59 | 7.5h |
| New York ↔ Mumbai | 09:31–12:29 | 19:01–21:59 | 3h |
| London ↔ Mumbai | 14:31–17:29 | 19:01–21:59 | 3h |
| Berlin ↔ Singapore | 15:31–15:59 | 21:31–21:59 | 0.5h |
| San Francisco ↔ Tokyo | 16:00–21:59 | 08:00–13:59 | 6h |
| London ↔ Sydney | 08:00–12:59 | 17:00–21:59 | 5h |
| New York ↔ Sydney | 18:00–21:59 | 08:00–11:59 | 4h |
| New York ↔ São Paulo | 09:31–20:59 | 10:31–21:59 | 11.5h |
A wide window is not automatically a good one. New York ↔ São Paulo has only a one- or two-hour offset, so the overlap is nearly the whole working day. London ↔ Sydney has a technically usable window that sits at breakfast on one side and late evening on the other.
Why whole-hour arithmetic is not enough
Three things break the naive version:
Half- and quarter-hour zones. India is UTC+5:30. Nepal is UTC+5:45. Chatham Islands is UTC+12:45 or +13:45. Rounding any of these to the nearest hour throws the window boundaries out by up to 45 minutes, which is enough to move a meeting slot.
Daylight saving on one side only. If one city observes DST and the other does not, the overlap changes twice a year. India never changes; the US does. So the New York ↔ Mumbai window moves by an hour, in a direction India has no say in.
Transitions on different dates. The US and the EU change on different weekends. For a few weeks each year a London ↔ New York window computed in February is an hour wrong.
The only reliable approach is to scan actual minute boundaries against real zone rules rather than to subtract offsets. That is what the figures above do.
How to compute it yourself
For a pair of cities and a waking range:
- Pick a start instant.
- Step forward a minute at a time.
- At each step, convert the instant into both cities' local times.
- Record where both fall inside the waking range.
- The first continuous run is the next shared window.
Stepping by the minute rather than the hour is what makes Kathmandu and Mumbai come out right, and what makes a window that straddles a DST change come out right too.
Choosing inside the window
Once you know the window, the remaining decision is human rather than arithmetic:
- Avoid the first and last thirty minutes. They get eaten by overruns.
- Prefer the end of the earlier city's day over the start of the later one's. People are more reliably present at 5pm than at 8am.
- If the window is under two hours, protect it. Do not spend it on status updates that could be written down.
Related: Time zone overlap · Working across time zones
Timezone: World Clock Widget
A world clock, converter and live day/night map for iPhone — 325 cities, offline, no account.
Figures on this page are computed from the IANA time zone database. Last generated 2026-08-18.