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, its window has to snap to whole hours, and the calculator snaps down. A 9am–5pm day in Asia/Kolkata really runs from 03:30 to 11:30 UTC, but on the band it marks the whole-hour cells 03:00 through 10:00. Two things follow. The first marked hour is half-generous: the band shows India available from 03:00, but nobody in Mumbai is at their desk until 03:30. And the last half-hour actually worked — 11:00 to 11:30 — doesn’t get a cell at all.

The practical rule: when your zone list includes a half-hour or 45-minute offset, treat the first overlap hour 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 start an hour later. The middle of a multi-hour overlap is always safe; it’s the edges that are blurred by up to 30 (or in Nepal’s case, 45) minutes.

”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 is silently skipped. It doesn’t error; it simply doesn’t get a row, and the overlap is computed across the zones that remain. That means a typo can make your overlap wider — you add the ninth colleague’s zone, misspell it, and the shared window happily grows because their constraint vanished from the math. The tell is visual: count the rows in the band. Six zones entered, five rows rendered — one of your identifiers didn’t parse. (The list is also capped at eight zones; a ninth line is dropped the same quiet way.)

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: count the rows and confirm every zone you typed actually rendered; 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 overlap hour 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.