Working-hours overlap is the time when every participant is available at once. Use actual local work hours and a specific date. Comparing fixed offsets alone misses daylight-saving changes, and comparing pairs can suggest a meeting that the whole team cannot attend.
Open the Working Hours Overlap Calculator. For a remote-job requirement, see the separate four-hour PST/PDT overlap guide.
Calculate the team's shared hours
- Select the UTC date. The search covers midnight to midnight UTC. Local workdays may start on a different date, and a shift crossing UTC midnight may require checking the adjacent UTC date.
- Select cities and enter local shifts. New York means America/New_York, rather than every place called Eastern Time. Set each person's actual start and end. Add up to 50 participants.
- Set the minimum useful duration. Use 30 minutes for a short call or 240 minutes for a four-hour collaboration window. The chart offers 15-, 30- and 60-minute cells; result boundaries are calculated to the minute.
- Click Find Overlaps. Check local start and end dates as well as clocks. A valid no-overlap result means the shifts need adjustment or the work should be asynchronous.
- Share or export. Share Setup links contain the setup; CSV exports include local dates, named time zones and UTC timestamps. Confirm the proposed time with the team before booking it.
Dated examples for ordinary 09:00–17:00 workdays
The table below uses the same local shift in each city on 15 January and 15 July 2026. It calculates all participants' intersection. The results are generated from the same time-zone calculation as the tool.
| Team | 15 January 2026 | 15 July 2026 |
|---|---|---|
| New York + London | 14:00–17:00 UTC (180 minutes) | 13:00–16:00 UTC (180 minutes) |
| London + Mumbai | 09:00–11:30 UTC (150 minutes) | 08:00–11:30 UTC (210 minutes) |
| London + Singapore | No shared time | 08:00–09:00 UTC (60 minutes) |
| New York + London + Los Angeles | No shared time | No shared time |
New York and London share three hours on both example dates, but the UTC window changes. London and Singapore have no positive-duration overlap in January: one finishes at the instant the other starts. In July, London's summer time creates one shared hour. Adding Los Angeles to the New York/London team removes the shared window on both dates.
Why transition weeks need their own calculation
In 2026, US daylight saving runs from 8 March to 1 November; the UK changes on 29 March and 25 October. New York and London therefore spend some weeks on a different relative offset. The 09:00–17:00 overlap on 15 March is 13:00–17:00 UTC: four hours, instead of January's three.
These dates come from NIST and the UK Government. Southern Hemisphere schedules change on another calendar; use the actual date instead of a universal winter/summer offset table.
Overnight shifts, fractional offsets and short windows
An overnight shift has an end clock earlier than its start, such as 22:30–02:30. On 15 January, Mumbai 22:30–02:30 overlaps Los Angeles business hours from 17:00–21:00 UTC. The Mumbai end date is 16 January, which is shown in the result and export.
Mumbai and Kathmandu working 09:00–17:00 share 03:30–11:15 UTC on the example dates. Their offsets differ by 15 minutes, so a half-hour chart alone cannot express every boundary. The exact result is authoritative; the chart highlights only fully available cells.
Equal start and end clocks mean all-day availability in this tool. The schedules repeat daily. Weekends, holidays, booked meetings and lunch breaks are not represented; account for those separately. A minimum-duration filter removes short windows rather than combining separate intervals into one uninterrupted meeting.
Keep the agreement practical
If no sustainable shared time exists, rotate the inconvenient call, agree a smaller collaboration window or move status updates to asynchronous work. Recheck recurring meetings after a clock change. Current browser and operating-system time-zone data matter because governments can change the rules; see the IANA database reference.
Calculations stay in the browser. Sharing puts the setup in a URL visible to recipients and services handling that URL. Avoid confidential details in shared links, and review the privacy policy for analytics and advertising.