To calculate work hours across time zones, convert each participant's local working-hours window to UTC, then find the intersection where all windows overlap. For a one-hour meeting, pick any hour inside that overlap; if no hour works, shorten the meeting or rotate the slot across a two-week cycle.
Why Simple Math Fails for Global Teams
Adding hours and subtracting minutes rarely produces a fair slot. A London manager who assumes “nine o’clock is fine everywhere” ends up with a designer waking at 4 a.m. in New York while a developer in Singapore is still eating breakfast. The difficulty is not arithmetic but constraint satisfaction: each person has a different awake window, and the meeting must sit inside all of them simultaneously.
The fix is to stop thinking in local clocks and start thinking in a single reference frame. UTC gives you that frame. Once every timezone is expressed relative to UTC, overlaps become a simple interval-intersection problem you can solve by hand in under a minute or automate in seconds with TimeForge.
Understanding Working-Hour Overlaps
An overlap is the time range where every participant’s working-hours window is active at the same moment. If London works 09:00–17:00 GMT, Singapore works 09:00–18:00 SGT (UTC+8), and New York works 09:00–17:00 EDT (UTC−4), you convert each to UTC and intersect.
London: 09:00–17:00 UTC Singapore: 01:00–10:00 UTC New York: 13:00–21:00 UTC
The common window is 13:00–17:00 UTC. Any hour inside that range works for all three. Outside it, someone is asleep, commuting, or on a call-heavy morning block. The key insight: the overlap is often narrow, so you pick the hour that touches the least number of people’s edges.
Step-by-Step Calculation Process
Work through these four steps for any group size.
- List each person’s local working-hours window (start and end).
- Convert each window to UTC using the offset for the relevant date.
- Find the latest start and the earliest end across all converted windows.
- Choose a meeting duration that fits inside that range.
Here is a concrete worked example. A London manager needs a one-hour sync with a developer in Singapore and a designer in New York.
London works 09:00–17:00 GMT. On a typical weekday, GMT equals UTC, so the window is 09:00–17:00 UTC. Singapore is UTC+8, so local 09:00–18:00 becomes 01:00–10:00 UTC. New York on EDT is UTC−4, so local 09:00–17:00 becomes 13:00–21:00 UTC.
Latest start: max(09:00, 01:00, 13:00) = 13:00 UTC. Earliest end: min(17:00, 10:00, 21:00) = 10:00 UTC. Wait — 10:00 UTC is earlier than 13:00 UTC, which means there is no overlap for a full hour. This is correct and instructive: Singapore’s afternoon ends at 10:00 UTC while New York’s morning begins at 13:00 UTC, leaving a gap.
To fix this, shorten the meeting to thirty minutes and check again. Latest start 13:00, earliest end still 10:00 — still no overlap. The real solution is to adjust assumptions: Singapore’s team may extend to 19:00 local (11:00 UTC), or New York’s designer may start at 08:00 local (12:00 UTC). With New York starting at 12:00 UTC, the overlap becomes 12:00–17:00 UTC, and a one-hour meeting at 13:00 UTC works for everyone: 13:00 London, 21:00 Singapore, 09:00 New York.
This example shows why you must verify each person’s actual hours rather than assuming a standard nine-to-five.
Handling DST and Holiday Shifts
Daylight saving time shifts the offset by one hour for part of the year, which can break a previously valid slot. A meeting that worked in November may fail in March because New York moved from UTC−5 to UTC−4. Holidays compound this: Singapore’s public holidays shift the entire working window, and some teams observe different calendars.
Handle this by checking the offset on the specific date of the meeting, not today’s date. Most timezone libraries do this automatically. When doing it by hand, note whether the date falls inside DST for each city. For example, London observes BST (UTC+1) in summer, so the same London window shifts one hour later in UTC terms during that period.
Holiday shifts matter when one participant takes a day off that others do not. A slot that worked last week may fail this week because a holiday moved someone’s availability. Re-check windows whenever the calendar changes, especially around quarter boundaries.
Using Visual Overlays for Quick Checks
A horizontal bar chart with one row per person makes overlaps obvious at a glance. Each bar spans that person’s working hours in UTC; the shaded region where all bars intersect is your candidate window. This visual approach catches edge cases faster than arithmetic because you see gaps immediately.
TimeForge’s working-hour overlay renders exactly this chart. Add teammates by city or IANA timezone identifier, and the tool draws each person’s awake window on a shared UTC timeline. The slot finder then ranks candidate hours by how comfortably they fit inside the overlap, coloring slots green when everyone is mid-day, yellow when someone is near the edge, and red when the slot touches night hours. For the London–Singapore–New York example, the overlay highlights 13:00 UTC as green because all three are comfortably inside their windows.
If you prefer to build this yourself, a simple HTML/CSS bar chart works. Each row is a flex container with a colored segment positioned using percentage widths calculated from the UTC bounds. No JavaScript is required for static layouts.
Sharing Results with Your Team
Once you have chosen a slot, share it in a way that removes ambiguity. A timestamp like “13:00 UTC” forces recipients to convert mentally, which introduces errors. A link that renders the same chart in each viewer’s local timezone eliminates that step.
TimeForge generates a shareable link that displays the overlap chart and the chosen slot in every recipient’s local time automatically. The London manager sees 13:00 GMT, the Singapore developer sees 21:00 SGT, and the New York designer sees 09:00 EDT — all from one link, with no manual conversion. Saved rosters let you reuse the same team setup for recurring meetings, so you do not re-enter timezones each week.
For one-off checks, a plain-text summary also works: list the UTC slot and each person’s local time. Keep it to three lines. Pair it with the visual overlay when the group is larger than four people, because text alone hides edge cases until someone complains.