Time zone research

Time Zones That Are Not on the Hour

Whole-hour arithmetic works for most of the world and fails quietly for the rest. Three zones in our ten-zone evidence set use offsets that are not a whole number of hours, and one of them moved between two such offsets within a single year. A scheduling tool built on whole-hour assumptions produces a wrong time without producing an error.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

If I assume every time zone is a whole number of hours from UTC, what breaks?

This research reports offsets read from the runtime's own time-zone database for 2026. It does not claim a complete list of non-hour offsets and does not describe the history or politics of any zone.

Try it on the anchor product: BeanNest Time /, BeanNest Time /converter/.

The measured non-hour offsets

Kolkata reports +05:30 in January and July with zero transitions, so its offset is 330 minutes all year. Kathmandu reports +05:45, an offset of 345 minutes. Chatham reports +13:45 in January and +12:45 in July, so it observes daylight saving while remaining a forty-five-minute offset in both states.

Why this defeats whole-hour arithmetic

Converting by adding whole hours produces an error of thirty or forty-five minutes. That is small enough to be missed in conversation and large enough to matter for a meeting start, a flight connection, or a deadline. The error is systematic rather than random, so it persists across every conversion.

Chatham is the harder case

Chatham both uses a forty-five-minute offset and observes daylight saving. A tool that handles half-hour offsets but assumes daylight saving shifts by a whole hour will misconvert Chatham twice. Our evidence file records both its January and July offset so the two states are visible rather than inferred.

Offset distribution in our evidence set

Of ten zones, three report a non-hour offset: Kolkata at thirty minutes, Kathmandu at forty-five, and Chatham at forty-five. Six observe daylight saving. The two properties are independent, which is the point: handling one does not imply handling the other.

How to verify a conversion

The reliable check is to read the offset for the exact date and zone from a time-zone database rather than to compute it. Our generator samples the runtime database hourly across the year, so every transition and every offset in the evidence file is read rather than assumed.

What this means for a scheduling tool

A tool that stores offsets as whole hours, or that assumes a one-hour daylight shift, will be wrong for a measurable minority of zones. The correct representation is a zone identifier plus a date, with the offset resolved at conversion time. That is what the evidence in this repository demonstrates.

Why fractional offsets exist

Offsets that are not whole hours usually reflect a zone whose local mean solar time differs from the nearest whole hour by a substantial fraction, and whose administration chose to keep that difference rather than round it. The result is a permanent thirty or forty-five minute displacement from the neighbouring whole hour. The guides describe the measured offset without speculating about the decision, because the evidence file records offsets rather than histories.

How a fractional offset compounds with DST

A zone with a forty-five minute offset that also observes daylight saving moves between two fractional values rather than between two whole ones. Chatham moves from plus thirteen forty-five to plus twelve forty-five, a one hour change applied to a fractional base. A tool that handles the fraction but assumes the daylight shift is a whole hour happens to work here, and a tool that assumes the base is whole fails twice.

Why rounding errors persist rather than cancel

A thirty minute error introduced by whole-hour arithmetic recurs on every conversion rather than averaging out, because the cause is a constant displacement. That is why the error is easy to miss in a single example and easy to detect in a series: every conversion is wrong by the same amount, and the amount is enough to change a meeting start, a connection, or a deadline.

The check that catches it

Reading the offset for the exact zone and date from a time-zone database catches every fractional case, because the database stores the true value. Our generator reads offsets that way and reports them with sign and minute precision, so a reader can compare any conversion against the evidence file directly. No arithmetic shortcut is involved on either side.

How a fractional offset arises

A zone's offset usually reflects a compromise between local solar time and administrative convenience. Where the solar difference from a whole hour is substantial, an administration may keep the fraction rather than round it, producing a permanent thirty or forty-five minute displacement. The evidence file records the measured offset without speculating about the decision, because the guides cite offsets rather than histories.

What the rounding error looks like in practice

A whole-hour assumption introduces a fixed displacement on every conversion for that zone. The error does not average out across a series, because the cause is constant. That is why it is easy to miss in one example and easy to detect in a run of examples, and why the measured offset is the reliable reference rather than a remembered rule.

How to check a conversion quickly

Read the offset for the exact zone and date from the evidence file and compare it with the offset the conversion assumed. If they differ by thirty or forty-five minutes, the conversion used whole-hour arithmetic and the error is structural rather than incidental. The check takes a few seconds and works for any zone in the set.

Why the measure is a count and not a percentage

Reporting that three of ten zones use a fractional offset is a statement about this evidence set rather than an estimate for the world. A percentage would imply a sampling claim the set does not make, since the zones were chosen to cover the distinct cases rather than drawn at random. The count describes the set, and the guides present it that way.

How the offsets were read

For each zone the generator formats a fixed instant in that zone and compares the result with the same instant in UTC, which yields the offset in minutes. Repeating this in January and July shows whether the zone changes offset during the year, and hourly sampling across the year finds the transition instants. No offset in the evidence file came from a table or from memory.

What the three fractional zones demonstrate

Kolkata at plus five thirty and Kathmandu at plus five forty-five show that a fractional offset can also be constant, since neither changes during the year. Chatham at plus thirteen forty-five and plus twelve forty-five shows that a fractional offset can also move. Those two patterns are the reason the guide treats fractional offsets and daylight saving as independent properties.

How a scheduling tool should handle the case

Resolve the offset from a zone identifier and a date rather than storing or assuming a whole-hour value. That single rule handles constant fractional offsets, moving fractional offsets, and whole-hour zones without special cases. The guide states the rule because it is what the measured evidence supports, not because it is the only possible implementation.

Why this matters more for deadlines than for conversation

A thirty minute error in a conversation is usually absorbed, while the same error can miss a submission deadline, a connection, or a payment window. The guide frames the consequence in terms of exact-instant events because those are where the measured error becomes material, and it avoids claiming an impact on cases where the error would be absorbed.

How the zone set was chosen

The ten zones were selected to cover the distinct cases rather than to sample the world: northern and southern daylight saving, a constant fractional offset, a moving fractional offset, a zone with no transition at all, and a range of whole-hour zones. That selection is why the count of three fractional zones describes the set rather than estimating a global proportion, and the guide states it that way.

What a constant fractional offset implies for scheduling

A zone that never changes offset produces no drift for its participants, which is the same property the no-transition whole-hour zones have. The fractional part matters only for the accuracy of a conversion, not for drift. Separating those two effects keeps the guide from conflating an arithmetic problem with a scheduling problem.

First-party evidence and provenance

How we checked this

We derived every offset and transition from the runtime's own time-zone database by sampling the zone offset hourly across the calendar year, then modelled a weekly meeting pinned to a fixed local wall-clock time in a reference zone. The generator is in this repository and the evidence file is its output. For this guide we read the January and July offset for each zone in the set and identified those whose offset is not a whole number of hours, including one that changes between two such offsets.

Method: We derived every offset and transition from the runtime's own time-zone database by sampling the zone offset hourly across the calendar year, then modelled a weekly meeting pinned to a fixed local wall-clock time in a reference zone. The generator is in this repository and the evidence file is its output.
Environment: Node.js on a desktop workstation, using the bundled IANA time-zone data. No network call, no hard-coded offset table, and no user data.
Captured: September 20, 2026
Reviewed by: BeanNest Studio

Repository evidence artifacts:

tools/research-evidence/time/transitions-2026.json
tools/research-evidence/time/README.md