Global Work Shift Overlap Calculator
Calculate how many hours two globally distributed teams actually share during their working days by converting both shifts to UTC and intersecting them. Use it to plan handoffs, standups, or pair-programming windows between offices in different cities.
Last updated: May 2026
Compare with similar
About this calculator
The calculator converts each team's local shift to UTC and returns max(0, min(end1_utc, end2_utc) - max(start1_utc, start2_utc)). Variables: team1Timezone / team2Timezone are UTC offsets in hours; team1Start, team1End, team2Start, team2End are local shift boundaries in minutes-since-midnight (or hours expressed as decimal). Conversion to UTC subtracts the offset (a 9 AM start in UTC+1 becomes 8:00 UTC). The intersection length is the genuine shared window - 0 means there is no overlap and you must invent one through extended hours or asynchronous handoff. Edge cases: shifts that cross midnight in local time (e.g. a 22:00-06:00 night shift) must be modeled as two windows or with negative-handling logic - the simple subtraction will produce a misleading negative span. Daylight saving introduces ±1 hour drift between regions for 2-3 weeks per year when one observes DST and the other does not. The calculator ignores lunch breaks, core-focus blocks, and meeting load - a 4-hour mathematical overlap with two existing standing meetings inside it may only have 2 hours of practical collaboration time. For asynchronous-first teams, zero overlap is acceptable and often preferable, so a 0 result is not automatically a problem. Crossing the international date line creates the additional wrinkle that Friday in one place is already Saturday in the other; weekend-only logic is not modeled here.
How to use
Example 1 - London team (UTC+0, 9:00-17:00) and Bangalore team (UTC+5:30, 10:00-18:00). Convert to UTC: London 9-17 UTC, Bangalore 4:30-12:30 UTC. Intersection: max(9, 4.5) = 9, min(17, 12.5) = 12.5. Overlap = 12.5 - 9 = 3.5 hours. That window (9:00-12:30 UTC) translates to London 9:00-12:30 and Bangalore 14:30-18:00 - both inside normal hours. Verify: at 11:00 UTC, London sees 11:00 (working) and Bangalore sees 16:30 (working); at 13:00 UTC, London is 13:00 (working) but Bangalore is 18:30 (after hours), so 11:00 UTC is inside, 13:00 UTC is not - consistent with the 9-12:30 UTC window. Example 2 - San Francisco team (UTC-8, 9:00-17:00) and Sydney team (UTC+11, 9:00-17:00). Convert to UTC: SF 17-25 UTC (i.e. 17 UTC through 01 UTC next day), Sydney 22-06 UTC (next day). Intersection on a single UTC day: max(17, 22) = 22, min(25, 30) = 25. Overlap = 3 hours, from 22:00-01:00 UTC, which is SF 14:00-17:00 and Sydney 09:00-12:00. Verify: at 23:00 UTC, SF is 15:00 (working) and Sydney is 10:00 (working). Note this required treating SF's afternoon and Sydney's morning carefully across midnight UTC - many calculators get this wrong.
Frequently asked questions
Why does my night shift produce a negative overlap?
Standard shift overlap formulas assume shifts run forward within a single 24-hour day (e.g. 9:00 → 17:00). A night shift that crosses midnight (e.g. 22:00 → 06:00) has end < start in the same day, which breaks the subtraction. The fix is to split the night shift into two windows - 22:00 → 24:00 and 00:00 → 06:00 - and compute overlap against each separately, then sum the results. Most spreadsheet implementations handle this with a conditional: if end < start then end += 24. The simple version of this calculator does not include that wrap-around logic, so for cross-midnight shifts you should compute manually or use a workforce-management tool that handles 24/7 schedules natively.
How does daylight saving time affect overlap between two regions?
DST creates two annual periods (spring and autumn) during which one region has changed clocks but the other has not, shifting the effective overlap by ±1 hour. For example, the US shifts on the second Sunday of March while the EU shifts the last Sunday - so for that intervening week, NY-London offset is 4 hours instead of 5, gaining one hour of overlap. India, Japan, and most of Africa do not observe DST at all, so the overlap with European or US teams oscillates twice a year against those fixed regions. The calculator uses static UTC offsets, so during DST transition weeks you should either temporarily adjust the offset you input or check timeanddate.com for the exact offset for the date range in question. Recurring calendar invites are particularly vulnerable to silent drift across DST boundaries.
What is a healthy minimum overlap to maintain for a globally distributed team?
Most research on distributed-team performance suggests at least 2-3 hours of overlap is needed to sustain synchronous collaboration (daily standups, ad-hoc pairing, real-time decision-making), while teams with under 1 hour need explicit asynchronous practices (written-first decisions, recorded standups, multi-day decision windows) to function well. Below 2 hours, the practical overlap degrades quickly once you account for lunch breaks, focus blocks, and existing recurring meetings - a 2-hour mathematical overlap often becomes 30 minutes of usable collaboration time. Teams operating with zero overlap (e.g. US ↔ India direct) tend to either rotate inconvenient hours between sides or structure work into self-contained units that minimize the need for synchronous handoff. Whichever model you choose, making the overlap explicit (rather than "assumed available") prevents one side from quietly absorbing all the asymmetry.
What are common mistakes when using a shift overlap calculator?
The most common mistake is using local clock times for both teams as if they were the same time scale - this gives garbage results because 9:00 in London is not 9:00 in Bangalore. Always convert to a common reference (UTC) first. Another frequent error is forgetting lunch breaks and core focus hours: a calculated 4-hour overlap that straddles both teams' lunch is really 2-3 hours of usable time. Teams also commonly ignore the international date line: SF Friday afternoon is Sydney Saturday morning, so the "overlap" technically falls on a non-business day for one side. Counting time only inside a single UTC day instead of properly handling shifts that span midnight UTC is another easy mistake - Sydney-SF specifically requires careful day boundary handling. Finally, treating the result as available time ignores meeting load: a team with a 4-hour overlap but 3 hours of existing standing meetings inside it has only 1 hour of true collaboration capacity.
When should I NOT use a shift overlap calculator?
If your team is fundamentally asynchronous-by-default (written decisions, recorded video, multi-day RFC cycles), optimizing for overlap is a category error - design instead for handoff quality and timezone-rotation fairness. Likewise, for 24/7 operations like security, on-call, or trading desks, you do not want overlap to be maximized; you want it minimized and predictable for clean shift handoffs of typically 15-30 minutes. The calculator is also wrong for one-off events (a single all-hands or training session) where you just need to pick a slot manually using a visual world clock. Do not rely on it for hiring or planning when more than two regions are involved - pairwise overlap can be high while the three-way intersection is zero, leading to false confidence. And for solo workers or fully synchronous one-region teams it is simply not relevant.