Time zone research
Why Storing a Time Offset Loses Information
An offset records the displacement from UTC for an instant. A zone identifier names a rule set that a time-zone database can resolve for different instants. The selected 2026 evidence makes the difference concrete: six of its ten zones change offset during the year, so one captured offset cannot represent those zones for every date in the file.
What this guide helps you decide
An offset and a zone both produce a time. What does storing the offset alone throw away?
This research explains the representational difference between an offset and a zone identifier, illustrated by transition counts from the runtime time-zone database. It does not describe any storage format's specification.
Try it on the anchor product: BeanNest Time /, BeanNest Time /converter/.
An offset answers one instant
A value such as -08:00 is enough to place one local time relative to UTC when the instant and offset are already known. The value itself does not contain the rule that says when the same named zone uses a different offset.
The selected zones show the missing rule
In the 2026 evidence file, six of ten configured zones record two transitions and four record none. For a changing zone, an offset captured in one season is not the offset recorded for the other season. The transition count is the direct evidence for that limitation inside this set.
Chatham makes the distinction visible
Pacific/Chatham is recorded at +13:45 in January and +12:45 in July. A stored +13:45 value correctly describes the January sample but contains no indication that the same zone is recorded at +12:45 later in the year.
A zone identifier can be resolved for another date
The repository generator keeps the zone identifier and asks the runtime database for each sampled instant. That is why one input zone can produce different offsets across the year without an offset table embedded in the guide. The behavior depends on the database version used by the runtime.
Do not turn this into a future-update guarantee
The evidence file describes the runtime database used to generate the 2026 artifact. It does not guarantee when a future runtime will receive a jurisdiction's rule change, and it does not prove how a specific calendar or database product stores or refreshes time-zone data.
What the representation choice preserves
For questions that compare multiple dates in the same named zone, preserving the identifier keeps enough information for the runtime database to resolve each date under its available rules. Storing only one offset preserves that one displacement but discards the zone identity needed for the same operation.
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 counted how many zones change offset within the year, which is what demonstrates that a stored offset has a shelf life while a zone identifier does not.
- 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
- Reviewed by
- BeanNest Studio
Repository evidence artifacts:
tools/research-evidence/time/transitions-2026.jsontools/research-evidence/time/README.md