Time zone research
Why Storing a Time Offset Loses Information
An offset answers one question about one instant. A zone describes a rule that maps instants to offsets across time, and that rule changes. Our evidence set shows six of ten zones changing offset at least twice within a single year, which means an offset captured at one moment does not describe the same zone at another. Storing the offset discards the rule.
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/.
What each representation can answer
Given an offset of minus eight hours, you can convert one instant. You cannot determine the offset that same zone will use six months later, because the offset carries no rule. Given a zone identifier and a future date, you can resolve the correct offset, because the database carries the rules.
The measured transition counts
In our evidence set, six zones report two transitions in the year and four report none. Every zone that observes daylight saving changes offset twice, once into and once out. An offset recorded in January for one of those zones is simply wrong in July.
Chatham shows the trap clearly
Chatham reports +13:45 in January and +12:45 in July. Both are forty-five-minute offsets, and they differ by a full hour. A stored offset of +13:45 does not hint that a +12:45 period exists, and a that tool assumes whole-hour daylight shifts will not derive it.
Why the loss is invisible
An offset always converts correctly for the instant it was captured. The failure appears later, when the offset is reused for a different date. Nothing about the stored value signals that it has a shelf life, which is why the mistake survives review.
The representation that does not lose the rule
Store the zone identifier and the date or instant, then resolve the offset at conversion time from a time-zone database. Our generator does exactly that: it reads every offset from the runtime database by date rather than storing a table, which is why its output includes transition counts and distinct shift values.
What this implies for an archive
A past event recorded only with an offset can still be displayed, because the instant is known. Reconstructing what local time a zone observed on a different date requires the zone rule, which the offset no longer carries. That is why the offset is sufficient for display and insufficient for reasoning.
Why offsets feel sufficient
An offset converts an instant correctly, and an instant is usually what a stored timestamp represents. For displaying a past event to the person who created it, the offset is genuinely enough. The insufficiency appears only when reasoning about a different date in the same zone, which is a case that arises in recurrence, future scheduling, and any analysis that spans a transition.
How a transition count exposes the gap
Six of ten zones in the evidence set change offset twice within a single year. For those six, a stored offset describes the zone correctly for part of the year and incorrectly for the rest. The transition count is the measurement that shows how much the offset has left out, and it is derived by sampling rather than by consulting a rule list.
Why the loss cannot be repaired later
Once only the offset is stored, the zone identity is gone, and no amount of later computation can recover which rule produced that offset. Several zones share offsets at various times of year, so the offset does not even narrow the zone to one candidate in general. The information is destroyed rather than deferred, which is why the representation choice matters at write time.
What the correct representation supports
Storing a zone identifier and an instant allows the offset for any date to be resolved on demand, which supports recurrence, future scheduling, and historical reasoning from the same stored value. Our generator demonstrates the resolution path by reading offsets from the database for each sampled instant rather than from a table, and that is the same operation a scheduling tool would perform.
Why the insufficiency is easy to miss
An offset always converts correctly for the instant it was captured, so it passes every immediate test. The failure appears only when the value is reused for a different date, which is a case that does not arise in a single conversion. That delay between cause and symptom is why the representation choice is often made without noticing the trade.
How many zones the evidence set puts at risk
Six of the ten sampled zones change offset at least once within the year. For those six, a stored offset is correct for part of the year and wrong for the rest. The count is the measurement that shows how much information the offset has discarded, and it is derived by sampling the database rather than by consulting a rule list.
How the loss shows up in different systems
A calendar stores a rule and renders per zone, so it retains enough information to handle transitions. A log line that records only an offset keeps the instant correct and loses the ability to say what local time the same zone used on another date. The same stored value therefore supports different questions depending on the system around it, which is why the guide distinguishes representation from storage.
Why sharing offsets between zones makes recovery impossible
Several zones occupy the same offset during parts of the year, so an offset does not identify a zone even in principle. Once the identifier is dropped, nothing in the remaining data distinguishes the candidates. The information is lost rather than hidden, which is a stronger statement than saying it is inconvenient to recover.
What the transition counts demonstrate
Six of ten zones changing offset within a year means a stored offset is wrong for part of the year for most of the sampled set. The measurement is what turns the representation argument from a principle into an observed proportion, and it is derived by sampling rather than by citing a specification.
How to apply the rule in a new system
Store the zone identifier and the instant, and resolve the offset at read time from a maintained database. That is the same operation the generator performs for every value in the evidence file, so the approach has a working reference in this repository. No offset table needs to be maintained, which removes the staleness risk entirely.
How the two representations behave under change
A stored offset is fixed and cannot respond to a rule change, while a zone identifier resolved at read time follows whatever rules the database contains. When a jurisdiction alters its schedule, the identifier-based value updates and the stored offset does not. That behavioural difference is the practical consequence of the representational one.
What the evidence supports and what it does not
The transition counts establish that offsets change within a year for most sampled zones, which is enough to show that a stored offset has a limited shelf life. The guide does not claim when a specific jurisdiction will change, because that requires legislative information the evidence file does not contain.
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