Finding Meeting Hours That Don't Wreck Someone's Sleep

Every distributed team eventually has the same conversation: “does 10am work for everyone?” followed by someone in Sydney doing mental arithmetic and quietly realizing that’s 2am their time. Scheduling across time zones feels like it should be simple addition and subtraction, but the moment a team spans more than two or three zones — or crosses a daylight-saving boundary — fixed-offset math stops working and someone ends up in a meeting at an hour nobody would choose on purpose.

Why “just add the hours” breaks down

The naive approach is to memorize offsets: “New York is UTC-5, London is UTC+0, Singapore is UTC+8.” The problem is that most of those offsets aren’t fixed. New York is UTC-5 in winter and UTC-4 in summer because of daylight saving time; London is UTC+0 in winter and UTC+1 in summer for the same reason — and because the US and UK don’t shift their clocks on the same calendar dates, the gap between New York and London actually changes by an hour for a few weeks each spring and fall, even though both cities individually only shift by one hour. Add a third zone that doesn’t observe DST at all — Singapore hasn’t since 1982 — and a spreadsheet of fixed offsets silently goes stale twice a year without anyone noticing until a meeting lands at the wrong hour.

The only reliable way to handle this is to work from the IANA timezone database (the same database behind America/New_York, Europe/London, Asia/Singapore identifiers), which encodes the actual historical and future DST transition rules for every region — not just a static offset. Any tool or script that hardcodes “UTC-5” for New York will be wrong for roughly half the year.

Projecting local hours onto a shared axis

The way to actually solve a multi-zone scheduling problem is to project everyone’s working hours onto a single shared axis — UTC is the natural choice, since it’s DST-free by definition — and then look for the hours where every zone’s window overlaps. Concretely: if your team works 9am–5pm local time in each of six cities, convert each city’s 9–17 window into UTC using that city’s current offset (accounting for whether DST is active right now), then find the UTC hours that fall inside every single converted window at once. Zones that span midnight in UTC terms — Sydney’s workday, for instance, often lands as two separate UTC slices — need to be merged correctly rather than treated as a single contiguous block, or the overlap calculation silently misses valid hours.

This is mechanically simple but tedious to do by hand for more than two or three zones, and it’s exactly the kind of calculation that’s easy to get subtly wrong once DST is involved — which is why doing it by memorized offset is a common source of “wait, is this meeting at the right time” confusion on distributed teams.

Reading an overlap band instead of doing the math yourself

Once every zone’s working window is projected onto the same 24-hour UTC axis, the visual pattern does the work: stack each zone’s window as a row, and the columns where every row has a mark are your overlap. A team split across US Pacific, US Eastern, London, Berlin, Singapore and Sydney working standard 9–5 local hours typically has a narrow overlap window — often just one or two UTC hours — that’s usually early morning for the Americas and early evening for Asia-Pacific. Wider individual windows (say, a team that’s flexible to 8am–6pm rather than a strict 9–5) usually widen the overlap by a comparable margin, since you’re loosening the constraint on both ends simultaneously.

The Time Zone Overlap Calculator does exactly this: enter up to eight IANA zone names and a working-hours window, and it renders the UTC band directly, using the browser’s built-in Intl timezone API so DST is always current — no manually updated offset table to go stale on you. If the result comes back as “no overlap,” that’s real, useful information too: it means the team’s chosen working hours genuinely don’t intersect, and the fix is either widening someone’s hours, accepting an async-first meeting culture for that pairing, or shifting one location’s core hours rather than pretending a live meeting slot exists when it doesn’t.

Designing around the overlap, not fighting it

Once you know the real overlap window — not the one you assumed — a few patterns make distributed scheduling less painful. Reserve the overlap hours for genuinely synchronous work: decisions that need real-time back-and-forth, onboarding, or anything where async written communication would take three days of back-and-forth to reach the same outcome. Rotate the burden of “early or late” meetings across the team rather than always defaulting to whichever zone is the company’s historical headquarters — a team that always schedules at headquarters’ convenient 10am is quietly asking every other zone to absorb the DST math and the inconvenient hour every single time. And when a team’s overlap is thin or nonexistent, that’s a signal to invest more in async tooling — recorded updates, written decisions with a comment window — rather than repeatedly forcing a live meeting into a slot that doesn’t comfortably exist for everyone.

If your team also spans currencies — contractors or freelancers billing in a different currency than they’re paid in — the Freelance Currency & Tax-Adjusted Rate Converter solves the parallel problem on the payments side. And if the team relies on scheduled jobs (backups, reports, deploys) that need to run in a specific zone’s local time regardless of the calendar, the Cron Expression Builder translates a cron schedule to plain English so you can confirm it actually fires when — and where — you think it does.

Time zone overlap isn’t a fixed fact about a team; it shifts with the calendar and with whatever hours each person actually agrees to work. Recomputing it properly, rather than trusting a offset table someone wrote down once, is the difference between a meeting time that works in June and one that quietly stops working in November.