Summary

  • RFC 9636 defines a portable binary representation of time-zone transitions; it does not define the source of those rules or prove that a particular file reflects the latest civil-time decision.
  • Version 1, the version-2+ block, a truncated interval, the footer and a version-4 leap-table expiration can give different boundaries to an otherwise valid parse.
  • The operational receipt must join zone intent, database release, object hash, covered interval, reader/version choice, ambiguity or expiration signals, rendered time and the application’s eventual action.

The invitation said 09:00 local time. Both systems accepted the file. One opened the maintenance window an hour before the other.

Nothing in that sequence requires a corrupt parser. One system may have consulted the 32-bit compatibility block, another the 64-bit block. One may have used a recurrence rule beyond the last stored transition, another a newer database release issued after a legislature changed its timetable. A syntactically valid result can still be the wrong receipt for the decision being made.

RFC 9636 turns a widely deployed UNIX convention into a precise Standards Track interchange format. It is deliberately modest about authority: the RFC specifies the object, not the source from which its data was assembled. The IANA Time Zone Database is one important source, maintained under a separate procedure. The file and the civil rule are connected, but they are not the same record.

A binary object with two historical layers

Every TZif object starts with a version-1 header and data block. Those transition values are 32 bits wide and stop at 2038. Version 2 and later append another header, a 64-bit data block and a footer. The older block remains for readers that cannot understand the newer layer.

That compatibility design is useful and dangerous in exactly the same way. A writer may place only a placeholder in the version-1 block. An obsolete reader must then behave as if there are no time changes or abbreviations, while a current reader skips to richer data. “Both parsed the same file” says nothing about which evidence each consumed.

The receipt should record the format version, reader capability, selected block, object length, count validation and file hash. It should also retain the source database and release identifier. Without those fields, a post-incident offset is difficult to reproduce and impossible to attribute cleanly.

Transitions describe a bounded rule history

The 64-bit block lists ascending transition instants. Each chooses a local-time type containing a UT offset, a daylight-saving flag and an abbreviation index. A type governs from its transition up to the next one. Before the first transition, type zero applies. After the last, the footer applies only if it is present and non-empty.

TZDIST can deliberately produce a truncated file. RFC 9636 makes the interval explicit: the data is valid from the first version-2+ transition up to, but not including, the last boundary when those truncation markers exist. A start-truncated file uses an unspecified placeholder before its first known instant. An end-truncated file can move to -00 and an empty footer.

That is not missing polish. It is honest evidence. The consumer that turns “unspecified” into a convenient offset has invented authority the object refused to provide.

The footer is not tomorrow’s legislature

The footer contains an optional POSIX-style TZ rule for computing local time after the final stored transition. When it is non-empty, it must agree with the last transition at the seam. That proves internal continuity at one boundary.

It does not prove that a government will keep the same rule. A later civil-time decision can require a new source release. Calling the footer a prediction encourages applications to hide the edition of the data that informed a future appointment. It is better understood as an extrapolation under the rule encoded when the file was generated.

The difference is operational. A calendar can store the civil intention, the chosen zone and the source edition separately. When the database changes, it can identify affected future events and seek a deliberate policy: preserve the instant, preserve the wall time, notify the organizer or require confirmation. A single cached UTC conversion cannot reconstruct that choice.

Version 4 gives uncertainty an expiration time

RFC 9636 adds version 4, allowing leap-second records to be truncated at the start and permitting the final record to mark when the leap table expires. Beyond that instant, the table no longer says whether a future correction exists.

Readers are allowed two broad responses: refuse post-expiration processing, or continue as if the expiration were absent, possibly reporting an error. Both choices can be conforming. They are not operationally equivalent.

The application must surface which choice occurred. Otherwise a continued calculation and a verified calculation become the same green status. The 27th CGPM resolution about discontinuing leap seconds belongs to another authority layer; it does not retroactively tell a deployed parser which table it loaded or how it treated expiry.

The media type also matters. application/tzif carries no leap records. application/tzif-leap can carry them where needed. A magic number or MIME label identifies a format class, not the completeness or freshness of a particular calculation.

Integrity is outside the file

TZif contains no executable code, but its counted arrays still require bounds checks. Readers should verify that calculated header and block sizes fit inside the actual object and that indices remain within their arrays. A successful four-byte magic check is not validation.

The format provides no built-in integrity or confidentiality. RFC 9636 requires an external security layer such as TLS for public-channel distribution because altered rules can damage calendaring and scheduling. Transport protection proves a session to an endpoint. It does not prove that the publisher chose the intended tzdb release, a cache is current or a local file was not replaced later.

Distribution evidence can be richer: source identifier, release, URL, ETag, fetch time, object hash, signature or package provenance, cache age and installation result. The application then needs its own receipt for the zone identifier it selected. A device’s requested zone can reveal location, so those logs require proportionate access controls even though the rules themselves are public.

Abbreviations and offsets do not identify intent

The designation CST can refer to Central, China or Cuba time. RFC 9636 leaves localized substitution to the reader and warns that abbreviations are ambiguous. A numeric offset is narrower still: several zones can share it now and diverge later.

RFC 3339 can represent an instant with an offset. RFC 9557 can attach additional information such as a named time zone. RFC 5545 carries calendaring and recurrence structures. None packages the exact TZif bytes, release, reader policy and later effect into the timestamp itself.

Around a clock change, a wall time may occur twice or not at all. Transition data identifies the shape of that ambiguity; the application still decides whether to choose the earlier instant, the later one, shift, reject or ask. The receipt must preserve that decision rather than claiming the file “converted” an intention it never received.

A civil-time result needs a chain of custody

A defensible record has at least seven joins:

  1. the human or application intention, including whether wall time or instant is authoritative;
  2. the selected zone identifier and how it was chosen;
  3. the source database, release and distribution provenance;
  4. the exact TZif object, format version and represented interval;
  5. the reader, block, footer and leap-expiration behavior;
  6. the rendered offset, designation, ambiguity and chosen instant; and
  7. the application decision and observed outcome.

This chain prevents a common category error. The format standard has authority over how bytes mean transitions. It does not have authority over a legislature, a user’s intended place, a cache refresh, a scheduler’s ambiguity policy or the eventual execution of a job.

Sources