What is the IANA time zone database (and why your phone uses it)?
If you've ever picked a city — `America/New_York`, `Asia/Tokyo`, `Europe/London` — out of a time-zone dropdown, that string came from the IANA time zone database. It's an open-source registry of every time-zone rule on Earth, maintained by volunteers, and it's the silent infrastructure underneath every modern app that touches time.
The fastest way to look up the current offset for any city is the time converter — pick the source and target zones and you'll see the IANA-style names in use.
What it is
The IANA time zone database (sometimes called the "tz database," "Olson database," or `tzdata`) is a text-format dataset listing every time zone rule that's been in effect anywhere on Earth, going back to roughly 1970. Each zone has a name like `Continent/City` (e.g., `America/New_York`, `Asia/Kolkata`) and a list of historical rules: when DST started, what offset was used, when the zone changed.
It's distributed as a series of plain-text files. They're parsed by every operating system and most programming languages to compute "what time is it in zone X right now."
Who maintains it
A small group of volunteers, with the IANA (Internet Assigned Numbers Authority) overseeing distribution. The original maintainer was Arthur David Olson, an American computer scientist who started the project in the 1980s. After Olson stepped back in 2011, Paul Eggert took over as the primary maintainer.
The data is contributed by people around the world who notice when their country changes time-zone rules. Updates happen 6–12 times per year. New releases are tagged like `2026a`, `2026b`, `2026c`.
Why "Continent/City" and not country names
Two reasons. First, countries can have multiple time zones (the US has 6, Russia has 11). Second, country borders change but cities mostly don't. `America/New_York` will mean the same thing in 50 years even if New York's state government changes its DST rules — the zone name is stable; the rules attached to it can update.
There are exceptions for places that don't have a famous city: `Antarctica/McMurdo`, `Pacific/Easter`, `Atlantic/Azores`. The selection of which city represents which zone is sometimes political (`Europe/Kiev` vs `Europe/Kyiv` was an issue in 2022).
What's in a zone definition
Take `America/New_York`. The data file describes:
- The base offset (UTC-5 in winter)
- DST rules: starts second Sunday of March at 2 AM, ends first Sunday of November at 2 AM
- DST offset: UTC-4 in summer
- Historical rules: when the rules changed (e.g., the 2007 DST extension under the Energy Policy Act)
Some zones have decades of history: when did Russia abolish DST? (2011.) When did Brazil? (2019.) When did the EU's DST schedule align with the UK? (1996.) All in the database.
How your phone uses it
When you see a clock on your phone showing the right local time after you fly to Tokyo, here's what happened:
1. Your phone detects you've changed location (via cell tower, GPS, or your manual selection)
2. It looks up which IANA zone applies to that location
3. It applies the zone's current rules — base offset + DST if applicable — to UTC
4. It displays the result on the clock
The zone data is shipped with the OS as part of `tzdata`. iOS and Android update it via OS updates. If a country changes its DST rules suddenly (this happens — Egypt did it in 2023 with weeks' notice), there's a delay before phones update.
Why it matters for developers
If you write code that handles dates and times, you almost certainly use the IANA database without realizing it:
- Python's `zoneinfo` module reads it directly
- JavaScript's `Intl.DateTimeFormat` uses it
- PostgreSQL's `timestamptz` and `AT TIME ZONE` use it
- Java's `java.time.ZoneId` uses it
- Almost every other language has a similar interface
The standard practice for time-zone-aware code: store dates as UTC, attach an IANA zone name (`America/New_York`) when display matters, let the runtime apply the rules.
When tzdata gets updated
Some recent examples:
- 2024 (tzdata 2024a): Mexico aligned border state DST rules with the US.
- 2023 (tzdata 2023b): Egypt re-introduced DST after a decade without it. Months later (2023c), Egypt abolished it again.
- 2022 (tzdata 2022d): Mexico abolished DST for most of the country.
- 2020 (tzdata 2020a): Yukon (Canada) moved to permanent Mountain Standard Time.
Each release gets propagated through OS updates. Servers running Linux usually update via `apt-get install tzdata` or equivalent. Vercel, AWS, and most cloud platforms keep their containers up-to-date automatically.
Common gotchas
Old aliases. Some zone names exist for backward compatibility but aren't recommended for new code. `US/Eastern` is an alias for `America/New_York`. `Asia/Calcutta` is the old name for `Asia/Kolkata`. Use the canonical name.
Zones aren't countries. A country with multiple zones (US, Russia, Brazil) has multiple IANA entries. A multi-country zone (`Europe/Berlin` covers Germany and several smaller European countries with the same rules) has one entry.
Etc/GMT signs are reversed. `Etc/GMT+5` is UTC-5 (yes, the sign flips, for POSIX-compatibility reasons). Use `Etc/UTC-5` mental model with caution. Most modern code avoids `Etc/` zones in favor of city-named ones.
FAQ
How do I know which IANA zone matches my city?
Look it up — most language libraries have a `tzdata` lookup function. For a person, the easiest is to use the time converter and pick the closest large city. The dropdown there uses canonical IANA names.
Why does the same zone sometimes have different abbreviations?
Because the abbreviations are seasonal. `America/New_York` is `EST` in winter and `EDT` in summer. The IANA database stores both and applies the right one based on date.
How often does tzdata change?
Roughly 6–12 releases per year. Most changes are minor (typos, minor border adjustments). Major changes happen when a country alters its DST rules — which can happen with little notice.
Is the IANA database authoritative?
Yes — it's the de facto global standard. ISO doesn't maintain a separate registry; ICANN doesn't either. The IANA database is the closest thing to an "official" global time-zone reference, even though its volunteer maintainership is informal.
Can I trust historical timestamps in tzdata?
Yes for post-1970 data, mostly. Pre-1970 data is included on a best-effort basis — many countries simply don't have well-documented historical rules. If you're working with dates from the 1800s, expect some imprecision.
Bottom line
The IANA time zone database is the silent infrastructure of modern timekeeping. Your phone uses it. Your operating system uses it. Every database that stores `timestamptz` uses it. It's open-source, volunteer-maintained, and updated as the world's time zones change.
For day-to-day conversions, the time converter and world clock handle IANA zones automatically — you just pick the city and it does the math.