Golden Overlap Windows for Every Major Time Zone Pair
Published August 18, 2026 by SyncHours Team
"What's the overlap between X and Y?" gets answered with vibes more often than arithmetic — "not much" or "actually pretty good" depending on who's asking. Below is the actual math for the ten time zone pairs that come up most often on distributed teams, assuming a standard 9:00am–6:00pm working day on both sides. Half of these pairs have real "golden" overlap — working hours meeting working hours. The other half genuinely don't, and for those, the honest fallback is a fringe-fringe compromise, not a golden window that doesn't exist.
Every pair below has a live scrubber if you want to drag through the day yourself rather than read a static table — links are in the last column.
The ten pairs, ranked by overlap size
| Pair | Offset gap | Golden overlap | Live scrubber |
|---|---|---|---|
| San Francisco (PST) / Singapore (SGT) | 16h | 1h — PST 5–6pm = SGT 9–10am | pst–sgt |
| New York (EST) / London (GMT) | 5h | 4h — EST 9am–1pm = GMT 2–6pm | est–gmt |
| New York (EST) / Berlin (CET) | 6h | 3h — EST 9am–12pm = CET 3–6pm | est–cet |
| London (GMT) / Bangalore (IST) | 5.5h | 3.5h — GMT 9am–12:30pm = IST 2:30–6pm | gmt–ist |
| San Francisco (PST) / London (GMT) | 8h | 1h — PST 9–10am = GMT 5–6pm | pst–gmt |
| San Francisco (PST) / Bangalore (IST) | 13.5h | 0h — no working/working overlap | pst–ist |
| New York (EST) / Bangalore (IST) | 10.5h | 0h — no working/working overlap | est–ist |
| San Francisco (PST) / Berlin (CET) | 9h | 0h — no working/working overlap | pst–cet |
| New York (EST) / Tokyo (JST) | 14h | 0h — no working/working overlap | est–jst |
| New York (EST) / Sydney (AEST) | 15h | 0h — no working/working overlap | est–aest |
Offsets shown are standard-time offsets, not adjusted for Daylight Saving Time — several of these gaps shift by an hour for part of the year, because the US, EU, and Australia don't start or end DST on the same date. SyncHours' scrubber resolves the correct offset for whatever date you're actually scheduling against; the table above is the year-round baseline.
That baseline-shift caveat matters more than it looks for the New York/London and New York/Berlin rows specifically. The US moves its clocks forward on the second Sunday in March; the EU doesn't move until the last Sunday in March — a gap of one to three weeks every spring where only one side of the Atlantic has sprung forward. During that window, the EST–GMT offset temporarily narrows from 5 hours to 4, which widens the golden overlap by an extra hour rather than shrinking it. The reverse happens in autumn: the EU falls back at the end of October, the US waits until the first Sunday in November, so there's a similar one-to-two-week mismatch window running the other direction. Teams that lock a recurring meeting to a specific UTC time and never revisit it are the ones who get caught by this — the meeting quietly drifts an hour off its intended local time twice a year until someone notices.
When there's no golden window, there's still a best window
Zero working-hours overlap doesn't mean zero usable overlap — it means the best available slot is fringe-on-both-sides rather than working-on-both-sides. That's a materially different, and much more honest, thing to tell a team than "these time zones just don't work together." Here's the best fringe compromise for each of the five zero-overlap pairs above:
| Pair | Best fringe-fringe compromise |
|---|---|
| San Francisco / Bangalore | PST 5:30–7:30pm = IST 7:00–9:00am |
| New York / Bangalore | EST 7:00–9:00am = IST 5:30–7:30pm |
| San Francisco / Berlin | PST 7:00–9:00am = CET 4:00–6:00pm |
| New York / Tokyo | EST 5:00–7:00pm = JST 7:00–9:00am |
| New York / Sydney | EST 4:00–6:00pm = AEST 7:00–9:00am |
Every one of these still costs someone a fringe hour — that's unavoidable at a 10+ hour offset. What it buys you is a slot where nobody is taking the call at 2am. If your team is on one of these pairs and needs a recurring meeting, see the fair rotation formula for how to stop the same person from absorbing that fringe cost every single week.
Why 9–6 is the right baseline to argue from
Every one of these numbers moves if you change the working-hours assumption, so it's worth being explicit about why 9am–6pm is the right starting point rather than, say, a wider 8–7 or a core-hours-only 10–4. Two reasons: it's close to a legal or contractual standard in most of the countries these cities sit in, so it's a baseline HR and legal teams will actually recognize; and it leaves an hour of slack on each end for the fringe classification to mean something. If you define working hours as 8am–8pm, there's no fringe left — everything is either working or rest, and you lose the distinction that makes a fair-rotation policy possible in the first place. Start from 9–6, and treat wider hours as a conscious trade a specific team opts into, not the default.
It's also worth separating two different questions that this table answers differently: "can these two people have a live conversation at all" (yes, for all ten pairs, using the fringe windows above) versus "can this team run on a normal 9-to-5 rhythm with real-time collaboration" (only for the top four pairs). Teams evaluating a new hire's location, or founders picking a second office, are really asking the second question, and a 0-hour golden overlap is a legitimate reason to lean async-first for that pairing rather than trying to force synchronous rituals across it.
Extending "working hours" changes the math
The 9–6 baseline above is deliberately conservative. If your team is genuinely fine treating 7am–8pm as fair game — common on smaller or more flexible teams — every pair in the zero-overlap group above gains a real, if narrow, working-adjacent window, and the golden-overlap pairs gain an extra hour or two on each end. Drag your own team's start and end times on the SyncHours planner to see how much that actually buys you before you assume a pair is unworkable.