What the IANA Time Zone Database Actually Is
If you have ever worked with dates and times in software, you have relied on the IANA Time Zone Database whether you knew it or not. It goes by several names — tz database, tzdata, the Olson database, or zoneinfo — but they all refer to the same thing: a collaborative, freely available catalogue of the world's time zones and the rules that govern them.
The word "catalogue" undersells it. The database does not merely list which regions sit at which UTC offset. It records the complete history of civil timekeeping for each region — every offset change, every daylight saving transition, every wartime clock shift, and every scheduled future rule — going back, in many cases, to the mid-19th century when local mean time gave way to standardized zones. When your calendar app correctly shows that a meeting in 1985 happened one hour off from the same wall-clock time today, that is the tz database at work.
It is text-based, human-readable, and small. The compiled binary form that ships on your computer is only a few megabytes. Yet it encodes one of the most quietly complicated datasets in computing.
A Short History
The project began in the 1980s under Arthur David Olson, who assembled the first version and hosted it on servers at the U.S. National Institutes of Health. For decades it was maintained largely through a volunteer effort coordinated over a public mailing list, which is why the older name "Olson database" still appears in documentation.
Paul Eggert took over as the primary editor and remains the long-standing coordinator of the project. His compilation of the accompanying theory.html document and the meticulous commit history has made the database as much a historical reference as a technical one.
In 2011, after a brief but alarming legal dispute over the historical data, stewardship moved to the Internet Assigned Numbers Authority (IANA), the same body that coordinates other core internet resources. IANA now publishes official releases, which is why "IANA time zone database" has become the canonical name. The work is still done by the same community of contributors; IANA provides an institutional home and a stable distribution point.
The Naming Convention: Area/Location
One of the database's most distinctive features is how it names zones. Instead of country names or raw offsets, it uses an Area/Location format, almost always anchored to a representative city:
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
The "Area" is usually a continent or ocean (America, Europe, Asia, Pacific), and the "Location" is a well-known city within the zone. This choice looks quirky until you understand the reasoning behind it.
Cities are stable; political boundaries and offsets are not. Countries split, merge, rename themselves, and change their clocks. A city, by contrast, is a fixed geographic point with a continuous timekeeping history. Naming a zone America/New_York rather than "US Eastern Time" or "UTC-5" means the identifier stays valid even as the rules attached to it evolve.
The database also deliberately avoids country names to sidestep political disputes and because a single country often contains several zones — the United States has more than a dozen. It picks the most populous or historically significant city in each distinct zone as a neutral label. When two regions have shared identical clock history since 1970, they share one zone; the moment their histories diverge, they get separate entries.
Why Raw Offsets Are Not Enough
A common beginner's instinct is to store a time as "UTC+5:30" and call it done. This works for a single instant, but it falls apart the moment you need to reason about future or recurring events, because offsets are not static properties of a place. They are the output of rules that governments change constantly and often abruptly.
Consider a few real examples the database has had to absorb:
- Samoa skipped 30 December 2011 entirely. To align its business day with Australia and New Zealand rather than the United States, Samoa jumped across the International Date Line, moving from UTC-11 to UTC+13. For anyone on the islands, that Friday simply did not exist.
- Countries abolish, adopt, or reschedule daylight saving time with little notice. The European Union has debated ending DST; several countries and U.S. states have changed their DST rules in recent decades. Turkey, Russia, and others have shifted their standard offsets outright.
- DST start and end dates drift. The United States moved its DST boundaries in 2007. Any system that hard-coded the old rule silently produced wrong times for weeks each year.
If you store only an offset, you cannot answer the question "what will the local time be in Santiago on 15 November next year?" — because the answer depends on rules that may not even be finalized yet. Storing the zone identifier (America/Santiago) plus the database lets software compute the correct offset for any moment, past or future, and recompute it automatically when the rules change.
This is the core value proposition: the tz database separates the identity of a place from the ever-shifting rules that determine its clock.
How It Is Maintained
Maintenance happens in the open. Proposed changes — a new DST rule, a corrected historical date, a government announcement — are discussed on the public tz mailing list, where contributors cite official gazettes, news reports, and government decrees as evidence. Accuracy is taken seriously; changes to historical data in particular are scrutinized against primary sources.
Releases are versioned with a year and a letter: 2024a, 2024b, 2024c, and so on. The number is the year; the letter increments with each release that year. Because governments announce clock changes on their own unpredictable schedules, there is no fixed release cadence — a quiet year might see two releases, while a year of political churn sees many. Systems are expected to update promptly, since a stale database can mean displaying the wrong time after a rule change takes effect.
Who Depends On It
Almost everything.
- Operating systems. Linux distributions ship
tzdataas a core package. macOS derives its zone data from the same source. Windows uses its own registry-based zones for legacy reasons but exposes IANA zones through the ICU library and modern APIs. - Programming languages. Effectively every mature date/time library reads from or bundles the tz database: Python's
zoneinfo, Java'sjava.time, the ICU project, PostgreSQL, JavaScript engines via ICU, Ruby, PHP, and many more. - Applications. Calendars, booking systems, financial trading platforms, log analysis tools, and scheduling services all lean on it, usually without their developers thinking about it.
This ubiquity is exactly why the database matters so much. A single, shared, carefully maintained source of truth means a meeting scheduled in one system displays correctly in another, across operating systems and languages, decades into the past or future.
If you want to explore the zones themselves, browse the full list of IANA time zones or see how they map across the globe in our directory of all time zones.
Frequently Asked Questions
Is the tz database the same as tzdata, zoneinfo, and the Olson database?
Yes. These are all names for the same project. "tzdata" usually refers to the data files as packaged for an operating system, "zoneinfo" to the compiled binary directory, and "Olson database" is the older historical name after founder Arthur David Olson. Today the official name is the IANA Time Zone Database.
How often is the database updated?
There is no fixed schedule. Releases are triggered by real-world events — a government changing its DST rules or standard offset, or a correction to historical data. Some years see a single release; others see several. Each is named like 2024a, 2024b, incrementing the letter through the year.
Why does it name zones after cities like America/New_York?
Cities are geographically fixed and have continuous timekeeping histories, whereas countries, borders, and offsets change over time. Using a representative city gives each zone a stable, politically neutral identifier that stays valid even when the underlying DST or offset rules change.
Can I just store a UTC offset instead of a zone name?
Only for a single fixed instant. For future or recurring events you should store the zone identifier, because offsets change with daylight saving and government decisions. The zone name plus the database lets software compute the correct offset for any date automatically.
Who runs the project now?
It is published by IANA, which took over stewardship in 2011, and coordinated by Paul Eggert with a community of contributors working over the public tz mailing list. The technical work remains a collaborative, volunteer-driven effort.