ForHosting KIT · Finance & money

Work hours overlap percentage calculator

A 9–17 day at UTC−5 and a 9–17 day at UTC+0 share only 3 hours, 14:00 to 17:00 UTC, which is 37.5% of the shorter day. Enter each team's offset and hours, night shifts included. Free in your browser.

  • Free
  • Runs in your browser
  • No sign-up
  • Your data stays on your device
Use it from WebAPIEmailTelegramApp soon
If you enter
Offset a
-5
Start a
9
End a
17
Offset b
0
Start b
9
End b
17
You get
Offset a label
UTC−5
Offset b label
UTC+0
Team a hours
8
Team b hours
8

Distributed teams constantly ask a deceptively simple question: if one group works nine to five in New York and another works nine to five in London, how much of those two working days is actually concurrent? A work hours overlap percentage calculator answers that with fixed UTC offsets and local start and end hours, not city names and not a daylight-saving database. Overnight shifts wrap midnight. Offsets stay inside plus or minus fourteen hours.

How two working days become an overlap percentage

A working day here is a half-open local interval from start hour to end hour on a twenty-four-hour clock, plus a fixed offset from Coordinated Universal Time. Team A in UTC minus five that works nine to seventeen occupies 14:00 to 22:00 UTC. Team B in UTC plus zero that works nine to seventeen occupies 09:00 to 17:00 UTC.

Those two intervals share 14:00 to 17:00 UTC, which is three hours. When end is earlier than start the local window is a night shift and wraps midnight before the UTC conversion; a Tokyo morning and a San Francisco afternoon often meet as a two-hour slice after that wrap. A full civil day is start zero and end twenty-four, which covers the entire UTC circle and therefore overlaps the other team for that team's whole duration.

Equal start and end is rejected as a zero-length day rather than guessed as twenty-four hours, because those two readings are ambiguous in spreadsheets.

Follow-the-sun support staffing

Measure concurrent minutes between two support desks so roster tools do not treat non-overlapping mornings as a shared shift.

Do overnight shifts and wrapping midnights work?

Yes. If end is earlier than start the window is treated as a night shift that wraps midnight locally, then converted to UTC before the intersection. A full day is start 0 and end 24.

Why is New York 9–17 and London 9–17 only 37.5 percent overlap?

UTC−5 09:00–17:00 is 14:00–22:00 UTC; UTC+0 09:00–17:00 is 09:00–17:00 UTC.

Does this use IANA time zones or daylight saving?

No. You supply fixed UTC offsets (hours, including fractional values such as 5.5). Named zones and DST transitions are out of scope so the result stays a pure, Date-free identity.

How is the overlap percentage calculated?

It is the shared time divided by the shorter of the two working days, times 100. Two 8-hour days that meet from 14:00 to 17:00 UTC share 3 hours, so the overlap is 37.5%. Each team's own share is shown too.

What if one team's day sits entirely inside the other's?

Then the headline figure is 100%, because every minute of the shorter day is concurrent. The per-team figures differ: the short desk is fully shared, while the longer day may be only half shared.

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

POSThttps://api.kit.forhosting.com/biz/work-hours-overlap-percent

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

curl -X POST https://api.kit.forhosting.com/biz/work-hours-overlap-percent \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"offset_a":-5,"start_a":9,"end_a":17,"offset_b":0,"start_b":9,"end_b":17}'
{
  "offset_a": -5,
  "start_a": 9,
  "end_a": 17,
  "offset_b": 0,
  "start_b": 9,
  "end_b": 17
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "biz.work_hours_overlap_percent",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

HTTPCodeMeaning
401unauthorizedMissing or invalid API key.
402insufficient_balanceYour balance doesn't cover the task price.
404unknown_typeThat task type doesn't exist.
429rate_limitedToo many requests. Use the webhook instead of polling.

You send six numbers—offset, start, and end for team A and the same three for team B—and the solver maps both windows onto a twenty-four-hour UTC circle, intersects them, and returns overlap minutes, overlap hours, the share of each team's day that is live-shared, and a headline overlap_percent equal to one hundred times the intersection over the shorter working day.

How two working days become an overlap percentage

Both days last eight hours, so the shorter day is eight hours and overlap_percent is one hundred times three over eight, or thirty-seven point five percent. The same identity is written on every successful response: utc equals local minus offset, modulo twenty-four hours; overlap is the intersection of the two UTC intervals on a circular day; overlap_percent equals one hundred times overlap_minutes divided by the minimum of team_a_minutes and team_b_minutes. Per-team fields overlap_percent_a and overlap_percent_b use each team's own duration as the denominator so a four-hour desk that sits entirely inside an eight-hour desk reports one hundred percent for the short team and fifty percent for the long team, while the headline figure stays one hundred percent because every minute of the shorter day is concurrent.

Input contract, response fields, and validation rules

Hours may be fractional. POST a JSON object with six required finite numbers. offset_a and offset_b are fixed UTC offsets in hours, each inside minus fourteen through plus fourteen inclusive; aliases include utc_a, team_a_offset, a_offset and the matching B names. start_a, end_a, start_b, and end_b are local clock hours from zero through twenty-four inclusive; aliases include team_a_start, a_start, team_a_end, a_end and the matching B names. When end_a is earlier than start_a the A window wraps midnight; the same rule applies to B. On success the body echoes the six rounded inputs and offset labels such as UTC−5, reports team_a_hours, team_b_hours, team_a_minutes, and team_b_minutes, publishes each window in UTC as team_a_utc_start, team_a_utc_end, team_b_utc_start, and team_b_utc_end with team_a_wraps and team_b_wraps booleans, and gives overlap_minutes, overlap_hours, overlap_percent, overlap_percent_a, overlap_percent_b, overlap_windows as an array of UTC start and end clocks, same_window when the two UTC intervals are identical, a one-line message, and the formula string. Example: offset_a minus five, start_a nine, end_a seventeen, offset_b zero, start_b nine, end_b seventeen yields three overlap hours, thirty-seven point five percent, and a single UTC window from 14:00 to 17:00. Failed validation—missing fields, non-finite values, an offset whose absolute value exceeds fourteen, a start or end outside zero to twenty-four, or a zero-length day—returns invalid_input naming the field and is never billed. Successful calls cost the published $0.002 base price with unit item.

Where a work-hours overlap percentage earns its keep

People operations teams use a work hours overlap percentage calculator when they write core-collaboration hours for a company split across two hubs: if New York and London share only three of eight hours, a policy that demands four live hours is not feasible without stretching one side. Invalid offsets and zero-length days do not consume balance. Keep offsets as the UTC± numbers already printed on tickets and server configs; this tool does not resolve IANA names such as America/New_York and does not apply daylight-saving transitions. If a region changes offset in March, send the winter number or the summer number you actually mean. Staffing models convert overlap_hours into concurrent seat counts so a follow-the-sun support roster does not pretend that a Tokyo morning and a California morning are the same shift. Sales and customer-success orgs schedule recurring calls in the intersection published as overlap_windows rather than guessing from a world clock. Contracting language that promises a minimum shared day can pin overlap_percent in a test instead of a screenshot. Pair examples when teaching: identical offsets and hours return one hundred percent and same_window true; New York versus London at nine to five returns thirty-seven point five percent; Tokyo nine to eighteen versus San Francisco nine to eighteen returns a short wrap-aware slice; an offset of fifteen demonstrates the hard invalid_input path. Pin overlap_percent and overlap_minutes in tests and you get reproducible concurrency math for handbooks, SEO landings, and edge workers without standing up a timezone database of your own.

Core collaboration hours for two hubs

Convert each office's local start and end plus UTC offset into overlap_percent and overlap_windows before you publish mandatory live-collaboration hours.

Recurring meeting slots across offsets

Place standing calls inside the UTC intersection returned as overlap_windows instead of guessing from a world-clock screenshot.

How is work hours overlap percentage calculated?

Each team's local start and end are shifted into UTC by subtracting the fixed offset, then the two intervals are intersected on a 24-hour circle. overlap_percent is 100 × overlap_minutes / min(team_a_minutes, team_b_minutes).

What does the work hours overlap percentage calculator cost?

The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.

Read the full KIT documentation →