What Is the IANA Time Zone Database?

Why “EST” Isn't Enough for Software

An abbreviation like EST is a label, not a rule. It doesn't say whether daylight saving applies this week, or what happened to that offset in 1970. Software needs something more precise, so it looks up a zone name instead: America/New_York.

That name is a key into the database, which stores the rules behind it. New York runs EST in winter and EDT in summer, on dates the database knows. Look up Asia/Kolkata and you get a single offset, because India doesn't use daylight saving today.

How Zone Names Are Chosen

Names follow an Area/Location pattern, where the area is a continent or ocean and the location is a city or small island. The convention is to use the most populous place in a region whose clocks have agreed since 1970, so the database says Asia/Shanghai and not Asia/Beijing. One name covers the whole region.

Names can still change. India's zone was once Asia/Calcutta, renamed Asia/Kolkata in 2008. The old spelling stays in a “backward” file so existing software keeps working.

Where This Database Actually Lives

It ships inside almost every system you use: Linux, macOS, iOS, and Android, plus Java, Python's zoneinfo module, and JavaScript's Intl API. PostgreSQL, Go, and Ruby use it too. On Linux and macOS the files typically sit under /usr/share/zoneinfo.

Inside, it's plain text. Zone lines list a name, a UTC offset, a rule set, and an abbreviation format. Rule lines describe when daylight saving starts and ends. A compiler called zic turns them into one binary file per zone. In a browser, Intl.DateTimeFormat().resolvedOptions().timeZone returns your own zone name.

One Name, Different Offsets Over Time

A zone name isn't a fixed offset. The database stores the history, so the same name gives different answers for different dates. Three examples, with the UTC offset on the 15th of the month shown:

That is why a converter has to ask for a date, and why storing only “UTC+3” for Moscow would be wrong for part of the past.

Who Keeps It Updated

Arthur David Olson started the project, which dates back to at least 1986, and that is why older references call it the Olson database. Today a small group of volunteers maintains it, led by Paul Eggert and Tim Parenti. The database and reference code are in the public domain.

It moved to IANA after a scare in 2011. A company sued the contributors over some historical data in the files, the mailing list was shut down, and ICANN took over maintenance on October 14, 2011. The lawsuit was dropped in February 2012.

Releases have no fixed schedule: 7 in 2022, 4 in 2023, 2 in 2024 and 3 in 2025. As of October 18, 2026 the newest is 2026e, from September 29, 2026. Release 2022f, on October 28, 2022, recorded that “Mexico will no longer observe DST except near the US border.” Release 2023a, in March 2023, recorded that Egypt uses DST again.

What It Can't Promise

The maintainers are blunt about the limits. They say the database is not authoritative and surely has errors, and that many, perhaps most, of its pre-1970 and future timestamps are either wrong or misleading. Future times are predictions, because governments can change a DST rule at short notice.

If a device's copy is out of date, it applies the old rule. For a zone that has just changed, that can put calculated times off by an hour.

Related Tools & Terms