Reading a Business Hours Overlap Matrix Across Time Zones

Say your company has an office in London and another in San Francisco. Someone asks, “what’s the best time to schedule a call between the two?” The honest answer requires more than a single number — it requires looking at both cities’ actual working hours side by side and finding where they line up. That side-by-side view is usually presented as a grid: hours of the day along one axis, each city’s typical business hours shaded in, and the overlap visible wherever both shadings intersect.

What the grid is actually showing you

A business-hours overlap matrix for two cities typically marks each hour of a 24-hour period as one of three states for each location: within typical working hours (say, 9am–5/6pm local), outside working hours but not unreasonable (early morning or evening), or asleep hours (typically late night to early morning). Reading the grid means looking for the columns where both cities land in the “working hours” state simultaneously — that’s your genuine overlap window, the stretch of time when a call doesn’t require anyone to be unusually early, unusually late, or asleep.

The width of that overlap window depends entirely on the two cities’ time difference and how their working-hour conventions compare. London and San Francisco, roughly 8 hours apart for most of the year (the gap narrows briefly around DST transition dates, since the US and UK change clocks on different dates), have a modest overlap: London’s late afternoon lines up with San Francisco’s early morning, giving a real but narrow window — commonly something like 8am–10am Pacific time, which is 4pm–6pm in London.

Some city pairs have essentially no working-hours overlap at all. A pair roughly 12 hours apart — for instance, a city on the US East Coast and one in India or eastern Australia — will typically show a grid where one city’s 9-to-5 falls entirely within the other’s overnight hours, with no shaded overlap in the “both working” state whatsoever. When that’s the reality, the honest conclusion isn’t “look harder for a good time” — it’s that any live meeting between those two locations will require someone to take an early morning or late evening call, and the fair approach is to rotate who absorbs that cost, as covered in our remote team meeting scheduling guide.

What counts as a “golden” overlap window

Not every hour inside the overlap is equally good. The best portion of an overlap window — sometimes called the “golden” window — is the part that falls comfortably inside normal business hours on both sides, rather than just barely qualifying at the edges. For the London–San Francisco example, 8am Pacific / 4pm London sits solidly in the middle of a workday for both cities; a call at 6am Pacific / 2pm London technically overlaps too, but it’s a much rougher ask for the Pacific-time participant, arriving before a typical workday has started for many people.

When a working-hours overlap is narrow, prioritizing the golden portion of it — rather than treating the whole overlap window as equally usable — is what separates a schedule that people can sustain from one that quietly wears out whoever’s on the losing end of the edge hours.

Reading the matrix with three or more locations

The two-city case is straightforward: find the columns where both shadings overlap. Add a third location — say, a team split across San Francisco, London, and Singapore — and the matrix gets meaningfully harder to read by eye, because you now need a column where all three shadings agree simultaneously, and that column may not exist at all.

In practice, three-way (or more) distributed teams often find that a true three-way overlap in comfortable working hours is thin or nonexistent, and the realistic options narrow to two: either accept a compromise window where one location is at the very edge of their working day (early morning or early evening, rather than the middle of the day), or split the meeting into two smaller two-way conversations that each have a genuine overlap, with a written summary bridging the two. Trying to force a single meeting that includes all three time zones in their comfortable hours, when the matrix shows no such column exists, usually means the meeting either runs at a bad time for someone every single week, or gets rescheduled so often that it stops being reliable.

A few high-traffic city pairs worth knowing

Some time zone pairs come up constantly for internationally distributed teams, and it’s worth having a rough sense of their overlap shape without recalculating it from scratch each time:

• US East Coast and Western Europe (roughly a 5–6 hour gap, narrowing or widening slightly around DST transition dates): a solid multi-hour overlap typically in the late morning for the European side and early-to-mid morning for the US East Coast side.
• US West Coast and Western Europe (roughly 8–9 hours): a narrower overlap, usually just an hour or two, generally early morning Pacific time against late afternoon in Europe.
• US and India (roughly 9.5–13.5 hours depending on which US zone and the half-hour offset of Indian Standard Time): overlap is thin to nonexistent for many US-zone pairings, which is part of why teams split across the US and India often lean heavily on async handoffs rather than daily live meetings.
• East Asia and Australia’s east coast (roughly 1–3 hours depending on the specific cities and DST in Australia): a comparatively easy pairing, with most of each side’s working day overlapping.

Building the habit into recurring meetings, not just one-off scheduling

A one-time meeting is easy enough to check by hand. The harder case is a recurring meeting — a weekly sync or standing 1:1 — set up months in advance and then left alone. The overlap matrix for that meeting’s original time slot was correct when it was scheduled, but it can quietly stop being correct after a DST transition on either side, since a meeting set as a fixed UTC time (rather than tied to each participant’s local time) will drift by an hour relative to whichever side’s clocks just changed. The safer pattern, mirrored in most modern calendar software, is to schedule recurring meetings by local time on each participant’s end rather than by a single frozen UTC timestamp, so the invite recalculates the correct instant automatically whenever a DST rule changes it — and it’s worth spot-checking a long-running recurring meeting around each March and October DST window specifically, since that’s when a silently wrong invite is most likely to surface.

These are rough patterns, not fixed numbers — the actual gap for any specific pair shifts with daylight saving time on whichever side observes it, which is exactly why a static reference table goes stale twice a year. The reliable way to check a specific pair is to look at both cities’ current live local time and typical working hours side by side rather than relying on a memorized offset. Our time zone converter lets you add any two cities and see this overlap directly, updated for whichever DST rules are currently in effect on either side, so the grid you’re reading reflects this week’s actual offset rather than a table someone filled in once and never revisited.