Why India and Nepal Break Your Meeting Scheduler

Most mental math for time zones assumes every offset is a whole number of hours — "India is five and a half hours ahead" gets rounded to "about six" more often than you'd expect, and that half hour is exactly the part that causes someone to join a call thirty minutes late. Fractional-hour offsets aren't a rare edge case either. They cover roughly 1.5 billion people, including two of the most common remote-hiring destinations on the planet.

Every fractional UTC offset in active use

Why these exist instead of just rounding to the nearest hour

Whole-hour zones are themselves a convenience, not a physical law — solar time changes continuously with longitude, and a country choosing UTC+5:30 instead of UTC+5 or UTC+6 is picking the offset that keeps solar noon closest to clock noon across its territory. India spans roughly 68°E to 97°E, which straddles the UTC+5 and UTC+6 lines; +5:30 was adopted in 1947 as the compromise that put the country's geographic center on a genuinely accurate clock, rather than forcing the whole country onto a neighbor's rounder number. Nepal's UTC+5:45 goes a step further and is defined relative to a specific meridian near Mount Everest — since 1986, the country has kept a fifteen-minute distinction from India's time, a difference small enough to be symbolic but large enough that scheduling software has to actually respect it rather than treat "South Asia" as one offset.

The actual bug this causes

Here's the concrete failure mode. Someone in New York schedules a 9:00am EST call and mentally converts for their Bangalore teammate by adding "5 or 6 hours" to reach evening. The real conversion: 9:00am EST is 14:00 UTC, and IST is UTC+5:30, so the correct local time is 7:30pm — not 7:00pm, not 8:00pm. A calendar tool, script, or person that rounds IST to a whole-hour offset is off by up to 30 minutes in either direction, and a 30-minute error on a meeting invite doesn't look like an error — it looks like someone joined late, or joined absurdly early and left before the real start time. Multiply this across a recurring meeting and it reads as unreliability on one side of the call, when the actual cause was a rounding assumption baked into whatever generated the invite.

The same failure hits Nepal harder, because 45 minutes doesn't even round cleanly to a half hour — tools that only support :00 and :30 as valid minute values for a timezone offset simply cannot represent Nepal correctly at all, and will silently substitute the nearest supported value.

When a fractional offset also has DST, it gets worse

Most fractional-offset zones skip DST entirely, which is one less variable to track — but not all of them. Newfoundland shifts from UTC-3:30 to UTC-2:30, Chatham Islands from UTC+12:45 to UTC+13:45, and Lord Howe Island (off Australia's east coast) has arguably the strangest rule of all: it's one of the only places on Earth where DST is a 30-minute shift rather than a full hour, moving from UTC+10:30 to UTC+11:00. A tool built to assume DST always means "add exactly one hour" will get Lord Howe Island wrong twice — once for the fractional base offset, and again for the fractional shift.

The practical takeaway for a hiring manager or team lead isn't to memorize every one of these — it's to treat "fractional offset" and "DST" as two independent facts about a location, confirm both before committing to a recurring time, and never assume a converted time is safe just because it looked right during onboarding. If your team also spans regions with staggered Daylight Saving transitions, pair this with the 2026 DST transition calendar so the two sources of drift don't compound unnoticed.

How to actually get this right

The fix isn't a better mental rounding rule — it's not doing the math by hand at all. Real scheduling needs to run off IANA time zone identifiers (Asia/Kolkata, Asia/Kathmandu) rather than fixed offset labels, because the identifier carries the exact fractional offset and any historical changes to it. SyncHours' scrubber is built on this data, so a stack including a half-hour zone lines up exactly rather than drifting: try London ↔ Bangalore, San Francisco ↔ Bangalore, or New York ↔ Bangalore directly.

If your team includes a fractional-offset city, the practical checklist is short: never state a meeting time as "add N hours" in writing without also stating the exact resulting local time; never trust a shared calendar invite that shows a whole-hour time for the fractional-offset attendee without double-checking it; and if you're hiring in one of the regions above for the first time, confirm your calendar and CI/cron tooling actually supports fractional offsets before the first invite goes out, not after someone misses a launch call.