When the Overlap Band Lies: Half-Hour Zones, "EST", and Other Meeting-Planner Edge Cases

You ran the numbers, the band says two hours of overlap, and the invite went out. Then the Mumbai half of the team joins thirty minutes into the “overlap,” someone points out that the zone list says EST instead of America/New_York, and by January the whole window has drifted anyway. None of these are bugs in the arithmetic — we covered how working hours get projected onto a shared UTC axis in our guide to finding meeting hours across a distributed team, and that math is sound. These are edge cases in the inputs and the grid: places where the real world doesn’t fit a tidy hourly band, and where knowing exactly how the Time Zone Overlap Calculator handles them is the difference between trusting the answer and being surprised by it.

Half-hour zones don’t fit an hourly grid

The overlap band works in whole UTC hours: 24 columns, each either inside a zone’s working window or not. That’s the right granularity for most of the world, but a meaningful slice of it doesn’t sit on the hour at all. India and Sri Lanka run at UTC+5:30. Nepal is UTC+5:45. South Australia (Adelaide) is UTC+9:30 in winter and +10:30 in summer. Newfoundland is UTC−3:30. Chatham Island, if you ever schedule with someone there, is UTC+12:45.

When one of these zones lands on an hourly grid, something has to give. When this post was first published, the calculator snapped such windows down. A 9am–5pm day in Asia/Kolkata really runs from 03:30 to 11:30 UTC, but the band marked the whole-hour cells 03:00 through 10:00. The first marked hour was half-generous, and the last half-hour actually worked, 11:00 to 11:30, got no cell at all.

This was fixed in August. The calculator now marks every UTC hour that a working half-hour touches, so the same Kolkata day fills the cells 03:00 through 11:00. Nothing that is actually worked gets dropped any more. The trade-off is that the band is now generous at both ends: it shows India available from 03:00, though nobody in Mumbai is at a desk until 03:30, and through the 11:00 cell, though they log off at 11:30.

The practical rule: when your zone list includes a half-hour or 45-minute offset, treat the first and last overlap hours as suspect. If the band says the shared window opens at UTC 03:00 and India is in the list, the real window opens at 03:30. Schedule on the half-hour, or trim an hour off each end. The middle of a multi-hour overlap is always safe. Only the edges are blurred: by 30 minutes for India, and for Nepal by 15 minutes at the start and 45 at the end.

”EST” is a real zone — and that’s the problem

The calculator takes IANA zone identifiers like America/New_York, and it validates them the honest way: by asking the browser’s Intl API. What surprises people is what counts as valid.

EST is a legitimate IANA identifier — for fixed Eastern Standard Time, UTC−5, forever, no daylight saving. Type EST meaning “New York” and your band is correct all winter, then silently one hour wrong from March to November, because the actual New York (America/New_York) moves to UTC−4 in summer while EST stays put. The same trap exists for MST, HST, and GMT. Meanwhile the Etc/GMT+5 family has inverted signs — Etc/GMT+5 means UTC−5, a POSIX-era convention that has ambushed sysadmins for decades. Older aliases like US/Eastern and Asia/Calcutta still resolve correctly, so they’re safe, just old-fashioned.

And then there are the names that aren’t zones at all. Asia/Delhi doesn’t exist (India’s zone is Asia/Kolkata). America/Los Angeles with a space instead of an underscore isn’t valid either. Here’s the behavior worth knowing. An invalid zone name gets no row in the band, and the overlap is computed across the zones that remain. That means a typo can make your overlap wider: you add a new colleague’s zone, misspell it, and the shared window grows because their constraint has left the math. When this post first went up, that skip was silent, and you could only catch it by counting rows. Since an August fix, the result line names the zone it left out, for example “Unrecognised and excluded: Asia/Delhi. Use IANA names like Europe/London.” So read the line under the hour count before you trust the number. (The list is also capped at eight zones, and a ninth line is still dropped without any message, so count the rows if your team spans more than eight zones.)

The band answers “today,” not “every Tuesday forever”

The calculator reads each zone’s offset at the moment the page loads. That’s a feature — it means daylight saving is always current, with no stale offset table — but it also means the answer is a snapshot. A recurring weekly meeting doesn’t live in a snapshot.

The sibling guide explains why fixed-offset math breaks around DST transitions; here’s what that means operationally for a standing invite. Northern and southern hemispheres shift in opposite directions, so cross-equator gaps genuinely swing. Los Angeles to Sydney is a 17-hour gap in July and a 19-hour gap in January — two full hours of movement across the year, enough to erase a narrow overlap entirely. Even same-hemisphere pairs wobble: the US and Europe change clocks on different dates, so for a couple of weeks each spring and autumn their usual gap is an hour off.

The habit that fixes this costs four visits a year: re-run your zone list shortly after each DST transition window (early March and early November for the US, late March and late October for Europe) and confirm the standing meeting still sits inside the band. If your team also runs scheduled jobs pinned to a local time, the same four dates are when cron schedules quietly drift too.

What the tool deliberately doesn’t model

Two limits are design choices rather than oversights, and they matter for specific teams. First, working windows are whole hours from a start to a later end on the same day — there’s no way to express a 9:30 start, and an overnight window like 22:00–06:00 comes back as zero hours, because a window can’t wrap past midnight. If you’re coordinating with a night-shift or follow-the-sun rotation, run the shift as two windows — 22:00–24:00 and then 00:00–06:00 — and merge the two bands by eye. Second, the overlap row lights up only where every zone is present. There’s no “best hour for seven of eight zones” mode; if the full-team overlap is empty, the tool tells you that plainly rather than nominating an hour that quietly excludes someone.

Both limits push the same direction: the band is a truth-teller, not a negotiator. It shows the hours that genuinely work for everyone, at whole-hour resolution, as of today.

A pre-invite checklist

Before you send the recurring invite, thirty seconds of hygiene: check the result line for an “Unrecognised and excluded” note, and count the rows if you entered more than eight zones; check the list for bare abbreviations like EST and replace them with real city identifiers; if any half-hour zone is present, nudge the meeting off the first and last overlap hours or onto the half-hour; and put a calendar note to re-check the band after the next DST changeover. Then open the Time Zone Overlap Calculator, paste your team’s zones, and read the edges of the band as carefully as the middle — that’s where all of these edge cases live.