The IANA Time Zone Database (tz database)

What the Database Actually Is

The IANA time zone database, also known as the tz database, zoneinfo, or simply tzdata, is a collaborative collection of information about the world's time zones. It is not just a list of offsets from UTC; it is a detailed catalog of the rules each place has used to keep time, including when and how those rules changed over the years.

For every zone it records the standard offset from UTC, the rules for daylight saving time, and the exact dates on which those rules took effect historically. With this data a program can answer questions like what the local time was in Berlin at a given instant in 1975, or whether a future appointment in Sydney will fall inside daylight saving time.

The database ships in two parts: human-readable source files describing the rules, and compiled binary files that operating systems read at runtime. A common misconception is that a time zone is just a fixed number of hours ahead or behind UTC. In reality a zone is a function of both place and moment, and capturing that function is exactly what this database does.

A Brief History

The project was started in the 1980s by Arthur David Olson, a programmer who began assembling the data and the code to use it, with substantial contributions from Paul Eggert, who became its longtime editor. Because of Olson's role the dataset is sometimes called the Olson database, and for many years it was distributed informally among Unix developers through mailing lists.

Over time the database became the de facto global standard, but its informal stewardship left it vulnerable. In 2011 a lawsuit briefly disrupted the mailing list and shook the community, prompting a search for a more stable home. Later that year the Internet Assigned Numbers Authority, or IANA, formally took over coordination of the database, which is why it now carries the IANA name.

Under IANA's umbrella the project gained institutional backing while keeping its open, volunteer-driven character. Today it remains a public, freely available resource updated by a small group of dedicated maintainers in cooperation with people all over the world who report changes in their own countries.

The Region/City Naming Scheme

Each zone in the database has an identifier in the form of a region and a representative location, such as America/New_York, Europe/Paris, or Asia/Tokyo. The first part is usually a continent or ocean, and the second is a major city chosen to represent everyone who shares the same history of clock changes.

The cities are deliberately not always the largest or the capital. A populous, long-established city is preferred because political capitals come and go, and the goal is a name that will stay meaningful for decades. The name identifies a shared timekeeping history, not a precise geographic point, so a single zone can cover a wide area.

This scheme is far more stable than naming zones after their current offset or after daylight saving abbreviations. Abbreviations like CST are ambiguous, since they can mean Central Standard Time in North America or China Standard Time, and offsets change whenever a government shifts its rules. By anchoring identifiers to enduring place names, the database keeps stored values valid even when the underlying clock rules change.

Recording Historical and Future Rules

One of the database's greatest strengths is its memory. It does not merely describe how a place keeps time today; it records the full sequence of rules a zone has followed, including past offset changes, the adoption and abolition of daylight saving time, and even historical oddities from before standardized zones existed.

This history matters because timestamps from the past must be interpreted with the rules that were actually in force then, not the rules of today. If a country abolished daylight saving in a particular year, a correct system needs to know that to convert old records accurately. The tz database encodes these transitions so that conversions remain faithful across the entire timeline.

The data also looks forward, encoding the known future rules for daylight saving transitions. Where a government has set permanent, predictable rules, the database can project them ahead. Where rules are announced at short notice, as often happens, maintainers update the data and downstream software must pick up the new release.

How Often It Updates and Who Uses It

Time zone rules are political decisions, and governments change them with surprising frequency and sometimes very little warning. A country may shift its standard offset, abolish daylight saving, or move a transition date for economic or social reasons. Because of this, the database is revised several times a year, with each release given a version such as 2024a or 2024b.

The reach of these updates is enormous. The tz database underlies the time handling in major operating systems including Linux, macOS, and the systems that power Android and iOS, and it is built into programming language runtimes for Java, Python, and many others. Web browsers and countless applications rely on it indirectly through these platforms.

Because so much depends on it, a single small edit by a maintainer can ripple out to billions of devices. When a country announces a last-minute change, the speed at which an update is published and distributed determines whether clocks around the world show the right local time on the day the change takes effect.

Why Software Should Use It Instead of Fixed Offsets

A tempting shortcut for developers is to store a time as a fixed offset from UTC, for example treating New York as always five hours behind. This breaks immediately, because New York is five hours behind in winter but only four hours behind during daylight saving time. An offset captures a single moment, not the rule that governs a place.

The correct approach is to store the zone identifier, such as America/New_York, alongside any future or local time, and let a library backed by the tz database compute the offset for the relevant instant. This way the software automatically respects daylight saving transitions and adapts when a government changes the rules, simply by updating to a newer version of the database.

Relying on the shared database also means relying on the collective vigilance of its maintainers and contributors, who track legislation worldwide so individual developers do not have to. Reinventing this work is both error-prone and unnecessary. For anyone building anything that handles dates and times across regions, leaning on the IANA time zone database is the difference between time that is merely approximate and time that is genuinely correct.