IANA tz database
Where zone names and rules come from — and why you must keep it updated.
The IANA Time Zone Database — also called the tz database, tzdata, or the
“Olson database” (after its original maintainer Arthur David Olson) — is the
authoritative source of time zone information used by Linux, macOS, most BSDs,
Java, Python, Go, and countless other systems. It maps named zones like
America/New_York and Europe/Paris to the complete history of UTC offsets,
DST rules, and transitions for each zone, going back to the 19th century in many
cases.
Zone names follow the pattern Area/Location (e.g. Pacific/Auckland,
Asia/Kolkata). These names are stable identifiers: even when a country
renames itself or reorganizes its zones, the database keeps the old name as an
alias (a “link”) pointing to the canonical current name, so existing software
continues to work.
Governments change DST start/end dates, abolish DST entirely, or adjust UTC
offsets — sometimes with very short notice. The IANA database is updated
several times per year in response (releases are versioned like 2024a,
2024b, …). A system running a stale tzdata may compute the wrong wall-clock
time for future or even recent dates in affected zones.
Why named zones, not fixed offsets
A fixed offset like +05:30 is sufficient for a specific historical instant,
but it cannot represent a future time correctly: you do not know in advance
whether a DST transition will shift the offset before then. A named zone like
Asia/Kolkata carries the rules to compute the correct offset at any point in
time — past, present, or future (subject to tzdata being current).
Pitfall: Storing a user’s time zone preference as a fixed offset (+02:00)
instead of a zone name (Europe/Helsinki) means future scheduling calculations
will silently use the wrong offset once DST rules change — storing the intent,
not just the current offset, is what preserves correctness.
Go deeper: tzdata versions, platform differences, and keeping it current
Where tzdata lives: On Debian/Ubuntu, it is the tzdata package; on RHEL/CentOS,
tzdata as well; on Alpine, tzdata is a separate optional package (not
installed by default in many Docker base images — a common oversight). macOS
bundles tzdata in /usr/share/zoneinfo and updates it via OS updates. Java
ships its own copy inside the JRE; the tzupdater tool or a JRE update is
required to refresh it independently of the OS.
Embedded copies: Many language runtimes and some libraries ship their own
bundled tzdata to remain portable. Go’s time/tzdata package can compile
tzdata directly into a binary. These embedded copies must be updated when the
library or runtime is updated — they do not track the system tzdata
automatically.
Deprecated zone names: Over time some zone names have been merged or
redirected. For example, US/Eastern is a link to America/New_York. Prefer
canonical Area/Location names; avoid the older US/, Canada/, Etc/GMT±N
forms where possible (Etc/GMT offsets have the sign convention reversed from
ISO 8601, which causes consistent confusion).
For the conceptual distinction between a named zone and a raw offset, see Time zones vs offsets. For how DST transitions interact with stored timestamps and scheduling, see DST.