What Is the IANA Time Zone Database, and Why Does Every App Rely on It?

When a phone shows the right local time after you land, the arithmetic is not in the airline’s app. It is in a public-domain dataset of civil-time rules, the IANA time zone database. People also call it the tz database, or tzdata. This site does not publish it, and it is not affiliated with IANA. The browser already has a copy. The converter asks that copy.

Who maintains it

No government and no company owns the contents. Volunteers, including historians and the programmers who consume the data, argue the changes on a mailing list. IANA distributes the releases. The project was started in the 1980s by Arthur David Olson, with Paul Eggert as the long-running coordinator, which is why older books still say “the Olson database.”

What the file is good for is not today’s offset. A search box can tell you that Tokyo is nine hours ahead of UTC. The database stores the history: every change a government actually made, the daylight-saving rules, and the rules needed to project the next transition. America/New_York in July is not UTC−5. It is UTC−4, and the identifier is what knows the difference.

Names are places, not numbers

Zones are named Area/Location: America/New_York, Europe/London, Asia/Shanghai, Australia/Sydney. An offset would go stale the day a parliament moved the clock. A place name can mean the whole history of that place’s civil time, which is what you need to answer “what time will it be in New York on this date next year.”

The city in the name is a representative, not a promise that it is the largest city, and not a separate zone per town. America/Chicago covers US Central time because those cities have shared one set of rules. Where they have not, the database splits them. America/Indiana/Indianapolis exists because Indiana’s counties spent years on different daylight-saving rules before the state mostly lined up in 2006. The identifier stays, because the history did not become identical just because the present did.

Releases are a year and a letter

There is no final edition. A government shortens daylight saving, cancels it, or moves a border city, and a release goes out with a name like 2024b or 2025a. Several of those can happen in one year. I am not going to call a letter “current” on this page. It would be wrong by the next decree.

That is why operating systems, browsers, and language runtimes have to update their copy. An application built in 2024, still running, will mis-convert any region whose rules changed after the snapshot it shipped. The code did not rot. The snapshot did. Morocco is the recent example. Decree 2.26.530 put the country on permanent UTC+0 at 02:00 on 20 September 2026. A browser whose tzdata is older than that decree still applies the 2018 rule, UTC+1 except during Ramadan. Two browsers then disagree, and both are “using IANA.” They are using different editions.

If a page on this site and your browser disagree, update the browser before you assume the page has an arithmetic bug. The about page says the same thing, because it is the whole method.

Old names still resolve

Code from the 1990s says US/Eastern and US/Pacific. Those names still work. They are compatibility links onto America/New_York and America/Los_Angeles, kept so that old programs do not break. New code should use the Area/Location name. The link is a courtesy, and it hides the fact that “Eastern” was never one history for every county that used the word.

The database also maps ISO country codes to the zones that country uses. That is what a settings screen is doing when it offers “United States” and then a short list, instead of every zone on earth. There are a few hundred zones. Most of them are irrelevant to a dropdown for one country.

Where the files are

On Linux and macOS the compiled data usually lives under /usr/share/zoneinfo, one file per zone. The C library reads those files. Windows spent a long time with its own zone data and a mapping toward tz identifiers. A language runtime often ships a private copy, on purpose, so a container that has no system zoneinfo still converts. The private copy is also how you get a correct answer on a laptop and a wrong one in a Docker image nobody has rebuilt since 2023.

What the browser actually calls

Intl.DateTimeFormat takes an IANA name. Ask it for Asia/Tokyo and it applies that zone’s rules, including the fact that Tokyo has not observed daylight saving since 1952. You do not add nine hours yourself, and you do not keep a special case for “countries that skip daylight saving,” because that special case is already in the data.

This site’s converter is that call. Each city is mapped to one identifier, and the browser does the conversion. Two current browsers agree to the minute. They will also agree on a half-hour offset, which a hand-rolled integer table will not. Those offsets are listed in half-hour and 45-minute time zones.

The limit is the edition, not the API. Intl will not tell you that its tzdata predates a decree. When a civil time looks wrong, the useful bug report is the city, the date, and what the browser showed. That is what the contact page asks for.