The IANA Time Zone Database

The /learn/time-zones-explained pillar introduces the IANA tz database as the authority for civil-time-zone information. This article goes deeper on the database itself: its 40-year history, the naming convention, the source-file structure, the release cycle, the institutional politics, and the software-integration landscape.

History: NIH origins to IANA stewardship

Arthur David Olson and NIH (1986–~2005)

Arthur David Olson, a computer scientist at the U.S. National Institutes of Health (NIH), started the database in 1986. The original use case: NIH biomedical computing needed accurate time-zone handling for laboratory data analysis, particularly for studies involving subjects in multiple zones over long periods.

Olson built on the C-language tzset() function (introduced in System V Unix) and extended it to handle the full history of zone rules rather than just current ones. His key insight: a single zone name like “America/New_York” should reference a complete history of offset and DST rules for that zone, allowing accurate computation of any historical local time.

Olson released the database publicly under what is effectively the public domain (the license is unusual but permits unlimited use, modification, and redistribution). He was assisted by a global community of contributors who researched historical time-zone changes and submitted corrections to the tz mailing list (tz@iana.org, the ongoing forum for database discussion).

Paul Eggert as primary coordinator (~2005–present)

Paul Eggert at UCLA has been the primary database coordinator since around 2005, when Olson reduced his active involvement (Olson retired from NIH shortly thereafter). Eggert has been a long-time contributor and took over the day-to-day maintenance work: reviewing patches, integrating updates from country sources, producing releases.

Eggert continues in the role today. His responsibilities include responding to country time-zone-rule changes, historical-research updates, software-correctness fixes, and coordination with platform vendors.

The 2011 Astrolabe lawsuit and IANA stewardship

In September 2011, Astrolabe Inc. — a Massachusetts astrology software company that published historical time-zone atlases — sued Olson and Eggert claiming copyright infringement over historical time-zone data in the tz database that allegedly came from Astrolabe's publications.

The lawsuit briefly took the tz database offline. The Electronic Frontier Foundation (EFF) organized legal defense pro bono. The case raised broader questions about copyright in factual data — historical time-zone rules are factual (a country either did or didn't observe DST in 1955) and not generally copyrightable, but the specific compilation might be.

Astrolabe withdrew the suit in February 2012 without extracting payment. The EFF noted the withdrawal as a victory for factual-data publication.

In the immediate aftermath, the maintainers sought institutional shelter. IANA (the Internet Assigned Numbers Authority, operated by ICANN) took over formal hosting in late 2011. In March 2012, the IETF published RFC 6557 (Procedures for Maintaining the Time Zone Database), formalizing IANA's stewardship and the maintenance procedures.

The technical work — Eggert's coordination, community contributions — continues as before. IANA provides the institutional weight, the bandwidth, the formal release infrastructure, and the legal shelter.

Naming conventions

The database uses a Region/City naming convention.

Region is a continent or ocean: Africa, America, Antarctica, Asia, Atlantic, Australia, Europe, Indian, Pacific. Plus Etc/ for offset-only zones.

City is the largest or most administratively important location in the zone. Spaces are replaced by underscores (New_York, not New York). Cities are chosen for permanence and recognizability — a zone named after a small town that might be renamed politically would be a fragile reference. The Region/City naming convention is documented in the tz-link.html and in the database's internal documentation.

When zones within a country have diverged historically — for example, when one region of a country observed different DST rules than another at some point — the database splits them with sub-regions:

America/Argentina/Buenos_Aires
America/Argentina/Cordoba
America/Argentina/Catamarca
America/Argentina/Mendoza
America/Argentina/Salta
America/Argentina/Jujuy
America/Argentina/Tucuman
America/Argentina/Rio_Gallegos
America/Argentina/Ushuaia
America/Argentina/San_Luis
America/Argentina/San_Juan
America/Argentina/La_Rioja
America/Argentina/ComodRivadavia (Link)

Each Argentine sub-region has different historical DST records; the database preserves all of them. Modern Argentine civil time is unified, but the historical divergence requires the sub-regions for accurate pre-2010 date computations.

Notable representative zones across the world:

Africa/Cairo            (Egypt — no current DST)
Africa/Johannesburg     (South Africa — no DST since 1944)
America/New_York        (US Eastern)
America/Chicago         (US Central)
America/Denver          (US Mountain)
America/Los_Angeles     (US Pacific)
America/Anchorage       (Alaska)
America/Honolulu        (Hawaii — no DST)
America/Sao_Paulo       (Brazil)
America/Mexico_City     (Mexico)
Asia/Kolkata            (India — UTC+5:30)
Asia/Kathmandu          (Nepal — UTC+5:45)
Asia/Tokyo              (Japan)
Asia/Shanghai           (China — single zone)
Asia/Dubai              (UAE)
Asia/Jerusalem          (Israel)
Atlantic/Azores         (Portugal Atlantic islands)
Europe/London           (UK — GMT/BST)
Europe/Paris            (France — CET/CEST)
Europe/Berlin           (Germany — CET/CEST)
Europe/Moscow           (Russia — UTC+3, no DST since 2014)
Australia/Sydney        (Australia East — AEST/AEDT)
Pacific/Auckland        (New Zealand)
Pacific/Chatham         (Chatham Islands — UTC+12:45)
Pacific/Kiritimati      (Kiribati Line Islands — UTC+14)
Antarctica/McMurdo      (US research station — uses NZ time)

The Etc/ zones provide offset-only references:

Etc/UTC           ← UTC
Etc/GMT           ← UTC
Etc/GMT-5         ← UTC+5  (sign reversed, see misconceptions)
Etc/GMT+5         ← UTC-5  (sign reversed, see misconceptions)

The sign-reversal in Etc/GMT names is a notorious gotcha, inherited from POSIX TZ-string convention. Use it only when unavoidable; prefer named Region/City zones.

Source-file structure

The tz database source is a collection of text files processed by the zic (zone information compiler) into binary .tzdata files consumable by C libraries.

Top-level source files:

| File | Contents | | -------------- | -------------------------------------------------------- | | africa | All African countries' zone rules | | antarctica | Antarctic research-station zone rules | | asia | All Asian countries' zone rules | | australasia | Australia, NZ, Pacific island zones | | europe | All European countries' zone rules | | northamerica | US, Canada, Mexico, Central America, Caribbean | | southamerica | South American countries | | etcetera | Etc/GMT, Etc/UTC, Etc/GMT+1, etc. | | backward | Old name aliases (Link entries from legacy names) | | factory | Reserved for factory-default systems | | solar87/88/89 | Saudi Arabia's solar time, deprecated | | leap-seconds.list | Leap-second history (separate publication) | | iso3166.tab | ISO 3166 country codes | | zone.tab | Mapping from country to zone name | | zone1970.tab | Modern zone-name table (post-1970) |

Within each zone file, the syntax is:

Zone NAME GMTOFF RULES FORMAT [UNTIL]

Plus Link lines for aliases. Example excerpt from northamerica:

Zone America/New_York   -4:56:02 -      LMT     1883 Nov 18 12:03:58
                        -5:00    US     E%sT    1920
                        -5:00    NYC    E%sT    1942
                        -5:00    US     E%sT    1946
                        -5:00    NYC    E%sT    1967
                        -5:00    US     E%sT

This shows New York's pre-1883 Local Mean Time (LMT, offset -4:56:02), the 1883 transition to standard time, and the subsequent DST-rule sources (US, NYC) through the years. The E%sT formats produce EST (standard) and EDT (daylight) automatically.

The release cycle

Releases are named with the year and a sequential letter: 2024a, 2024b, 2024c, etc. Typically 4–10 releases per year. Each release is announced on the tz-announce mailing list and published at data.iana.org/time-zones.

Triggers for releases:

• Country rule changes: when a country, territory, or state changes time-zone rules (offset change, introducing or abolishing DST, splitting or merging zones), an urgent release captures the change.
• Historical research: refinements to pre-1970 data as researchers find authoritative records of past zone rules (railway schedules, government archives, newspaper publication times).
• Bug fixes: corrections to existing rules, naming fixes, or zic-compiler improvements.
• Periodic maintenance: occasional refactoring, documentation updates.

Recent operational changes that triggered releases include Turkey's 2016 abolition of DST, North Korea's 2015 shift to UTC+8:30 and 2018 reversion to UTC+9, the Russian 2014 zone consolidations, the 2022 Casey Station Antarctica change, and many others.

Major operating-system vendors consume releases on their own schedules. Linux distributions typically ship the latest release within days. Apple updates macOS and iOS in scheduled OS updates. Microsoft maintains its own zone-name space for Windows (with periodic mappings to IANA names) and updates more slowly.

Software integration

The tz database is the time-zone source for essentially every major platform:

• Linux / macOS / BSDs: /usr/share/zoneinfo/ — binary tz files compiled from sources.
• Java: JVM bundles the tz database; updates via tzupdater tool or with JVM updates.
• Python: standard-library zoneinfo module (since Python 3.9; previously pytz package).
• Node.js: built-in Intl.DateTimeFormat accepts IANA zone names; tz database bundled with the ICU library.
• .NET: bundles IANA + Windows zone names with mappings (TimeZoneInfo).
• Go: bundles tz database in standard library (time/tzdata).
• Ruby: depends on system tz database or the tzinfo gem.
• PHP: bundles tz database; DateTimeZone accepts IANA names.
• Rust: chrono-tz crate bundles the database.
• PostgreSQL: pg_timezone_names view exposes the tz data; columns like TIMESTAMP WITH TIME ZONE use it.
• MySQL: depends on imported tz tables.
• Oracle, SQL Server: bundled or imported.
• Web browsers: through the ICU library and the Intl JavaScript API.

The de-facto effect: every modern computing platform agrees on civil-time-zone handling because they all use the same tz database. The exceptions are legacy systems and Windows' native zone-name space (covered next).

The Windows zone problem

Microsoft Windows historically used its own time-zone name space, with names like:

Pacific Standard Time
Central European Standard Time
India Standard Time
Tokyo Standard Time

These are not IANA zone names. A program that stores “Pacific Standard Time” in a database can't be portably interpreted on a Linux or macOS system without mapping to the IANA equivalent (America/Los_Angeles).

The CLDR (Common Locale Data Repository) project publishes a Windows-to-IANA mapping table that's the de-facto standard. Modern .NET and modern Windows (Windows 10+) increasingly accept IANA names directly, but legacy Windows code and many enterprise databases use the Windows-native names. Cross-platform applications often maintain their own mapping or use a library like xunit-timezone-mapping or the CLDR data directly.

Working with the tz database

For application developers, key patterns:

1. Always store IANA zone names (America/New_York, not EST). Abbreviations are ambiguous.
2. Trust the IANA database — don't reimplement zone rules manually. Even simple-seeming logic like “Eastern time is always UTC-5 in winter” has historical exceptions that the tz database knows about.
3. Update tz data regularly — at least annually, ideally on each release. Outdated tz data misses recent country rule changes; an application using a 2020 tz release won't correctly handle a country that changed rules in 2023.
4. Use the system tz on Linux/macOS rather than bundling your own. The system gets updates from the distribution package manager.
5. For Windows interop, use the CLDR mapping or one of the language-bindings (e.g., NodaTime in .NET) that handles the mapping automatically.

Common misconceptions

“The tz database is a US-only project.” It's used worldwide and tracks every country's zone rules. The maintainer is at UCLA and the database is hosted by IANA (ICANN, US-headquartered), but contributions come from researchers and governments worldwide. The database covers every sovereign state.

“Etc/GMT+5 is UTC+5.” It's UTC-5. The Etc/ zone names follow POSIX TZ-string convention, which uses the opposite sign from common usage. Etc/GMT+5 means “5 hours west of GMT” = UTC-5. This is a notorious gotcha. Use Region/City names to avoid the confusion entirely.

“The database covers all historical times.” It covers the post-1970 era reliably and provides best-effort coverage for earlier periods. Pre-1970 data is incomplete and subject to revision as historical research uncovers authoritative records. For pre-1970 applications, the database is the best available source but should not be treated as definitive.

“Zone names like 'America/New_York' are locked in.” They're stable as published, but the database does occasionally introduce new names or deprecate old ones. Deprecated names remain accessible as Link entries in the backward file; applications should gracefully follow links rather than failing.

“The database covers leap seconds.” It includes a leap-seconds.list file with the historical record, but most consumers ignore it (they get leap seconds via NTP and the system clock subsystem). The tz database's primary role is civil-time-zone rules, not leap-second distribution.

“tz database releases are backwards-compatible.” Mostly yes, but occasional zone renames or splits do happen (the 2008 Australian zone restructuring was a notable case). Applications that hard-code specific zone names should test against new releases.

“IANA created the database.” IANA hosts and provides administrative stewardship since 2011. The database was created by Olson at NIH in 1986 and was maintained on personal infrastructure for decades before IANA took over.

“The Astrolabe lawsuit is settled precedent.” Astrolabe withdrew the suit; no judgment was issued. The legal status of historical time-zone-rule data's copyrightability is therefore unsettled in U.S. law. The pragmatic effect — IANA stewardship — has held since 2011, but the lawsuit was withdrawn rather than dismissed on merits.