On this page
Separate instants from wall-clock text
The Time Zones source date is the published 2026e release date, 29 September 2026, not a retrieval date; it was checked on 22 October 2026. The other source dates record documentation retrieval. An instant identifies a point on a timeline; a local wall time is text interpreted through a zone rule. Keep the original string, offset if supplied, parsed instant if verified, timezone key, and precision. Do not replace a local string with UTC and discard the source representation because the original may be needed to explain an ambiguity or a conversion change.
A timestamp without an offset or zone key is not automatically UTC. Record whether the source intended local time, fixed offset, or an already normalized instant. If the source has only wall-clock text, keep the conversion as a hypothesis until the owner supplies the zone and policy.
| Timestamp field | Record | Unknown if |
|---|---|---|
| raw text | exact representation and encoding | Only a rendered value remains |
| instant | UTC value if conversion verified | Zone rule is missing |
| zone key | IANA identifier or fixed offset | Abbreviation is used alone |
| offset | observed or derived offset | Offset was overwritten |
| precision | second, millisecond, or unknown | Subsecond digits were dropped |
| conversion direction | local to instant or inverse | Transformation order is unclear |
Record the timezone database and runtime source
IANA describes tzdb as data and rules that change when governments change civil-time boundaries and offsets IANA, (opens in a new tab). Preserve the release label or package version used by the producer and consumer when available. “America/New_York” or another zone name identifies a rule family, not the exact ruleset loaded for a historical conversion.
Python’s Python Software Foundation, (opens in a new tab) implementation uses system data when present and can fall back to a first-party package. That is a reproducibility clue: record the source, version, runtime, and fallback path rather than assuming every machine has the same rule database. If the version cannot be measured, say so.
| Version field | Evidence | Hold condition |
|---|---|---|
| zone key | canonical IANA key | Only an informal abbreviation exists |
| tzdb release | release label or package metadata | Version unavailable |
| runtime source | system, package, or embedded rules | Fallback unknown |
| conversion library | name and version if observed | Implementation is unstated |
| offset at instant | observed and derived comparison | Only local text is retained |
| maintenance date | next check after rule updates | No owner for refresh |
Keep ambiguous and nonexistent local times explicit
When clocks move backward, a local time can occur twice; when they move forward, a local interval can be absent. A parser may choose a default fold, shift a gap, reject it, or attach an implementation-specific policy. Record the policy and preserve the original wall time. Do not select the earlier or later instant merely because one choice produces a cleaner sort order.
The IANA, (opens in a new tab) material explains that civil-time rules are controlled by governments and can change with little notice. That supports a maintenance boundary, not a promise that a future rule can be predicted. A comparison with unresolved folds or gaps should be conditional and should show the affected scope.
Ambiguity fields
- raw local string and stated offset, if any
- zone key and tzdb release
- fold or gap state and chosen policy
- derived instant plus conversion direction
- source sequence and precision
- unavailable fields preserved as unavailable
Use a text fixture for conversion policy
The fixture below uses an invented zone label so it cannot be mistaken for a real location. It tests an ambiguous local time, a missing tzdb version, and a fixed-offset value. Keep the example textual rather than executing conversions. The goal is to show what the worksheet must retain before a runtime supplies a result.
Do not insert private event times, customer locations, or production identifiers into a public timezone example. If a real conversion is necessary, record only an approved, minimized sample and the exact source and runtime evidence.
| Synthetic finding | Disposition | Next evidence |
|---|---|---|
| Zone key and release recorded | continue | Check offset and conversion direction |
| Fold is unresolved | hold comparison | Owner chooses ambiguity policy |
| Only abbreviation supplied | hold | Obtain canonical zone or fixed offset |
| tzdb version unavailable | conditional | Record measurement limitation |
| Precision differs between files | normalize cautiously | Keep original precision |
Synthetic timezone evidence
raw: 2026-11-01 01:30
zone_key: America/Example
tzdb: unavailable | fold: unresolved | precision: minute
comparison: fixed_offset=+00:00 value kept separate
disposition: do not sort or compare until rule set and fold policy are knownCompare with a reproducible timestamp contract
A sound comparison includes the source representation, parsed instant, zone key, tzdb version, offset, precision, ambiguity policy, and unknowns. If two values were normalized with different rule sets, report that the conversion evidence is not comparable. Keep the original wall time so a later rule update can be audited.
Link to the timestamp guide for general source and offset fields, but make the database-version question explicit here. A UTC string alone does not prove the original local time or source clock was correct.
| Finding | Disposition | Do not infer |
|---|---|---|
| Same zone key and release, verified conversion | bounded pass | Source clock is accurate |
| Zone key same, release different | recheck | Values are necessarily wrong |
| Fold or gap unresolved | hold affected rows | Parser default is correct |
| Fixed offset used intentionally | record as distinct | It is an IANA zone |
| Version unavailable | measurement limitation | Cross-runtime results match |
Close with a qualified preparation step
Once timestamp representation, zone key, rule-set version, precision, and ambiguity policy are recorded, keep the packet technical. Use the data provenance log for runtime and transformation history and a data card for source scope. Do not upload event logs merely to test a timezone question.
For a supported non-health collection, with authority to describe the timestamp fields and a controlled handling boundary, the qualified appraisal path may be a next preparation step. It does not convert dates, certify clocks, create a quote, match a buyer, issue a legal opinion, or grant a license. Reproducible time conversion is not proof of complete or shareable data.
Takeaways
- Keep wall time, instant, offset, zone key, and precision together.
- Record tzdb release and runtime source when available.
- Treat folds and gaps as explicit states, not parser defaults.
- Compare only bounded conversions with matching rule-set evidence.
- Keep timestamp reproducibility separate from source accuracy and rights.