Every phone, laptop and server that shows the correct local time is quietly consulting the same source: the IANA time zone database. It is not a treaty, a law or an international standard. It is a set of plain text files, curated largely by volunteers, that records what each region of the world has done with its clocks — the offsets from UTC, the daylight saving rules, the political redrawings — and it sits underneath very nearly every operating system in use today.
This article explains what the database contains, who maintains it, how its zone identifiers are constructed, how often it changes and why any program that handles dates depends on it. To see the data in use, the time zone browser lists every zone the database defines alongside its current local time.
What Is the IANA Time Zone Database?
The IANA time zone database is a collection of files describing the local time rules of every inhabited region on Earth, past and present. It maps a zone identifier such as Europe/London to the sequence of UTC offsets and daylight saving rules that have applied in that place.
It is more commonly called the tz database, and older documentation calls it the Olson database after Arthur David Olson, the software engineer who began assembling it in the 1980s. The project ships in two parts: tzdata, which holds the rules, and tzcode, the reference implementation that reads them. Between them they answer a question that sounds trivial and is not — what did, or will, a wall clock in this place read at this instant?
The data is deliberately historical. For any moment after 1 January 1970, the Unix epoch, the tz database aims to reproduce the local time that a clock in that region actually showed. That is why it can tell you not only that Berlin is currently one hour ahead of Coordinated Universal Time, but that a timestamp from 1979 in Berlin fell inside a daylight saving period that began on a date modern rules would not predict.
Who Maintains the Time Zone Database?
A small group of volunteer contributors maintains it, coordinated for many years by Paul Eggert, with the Internet Assigned Numbers Authority acting as its formal steward since 2011. Proposals are argued out in public on a mailing list rather than decided behind closed doors.
The process is unglamorous and effective, and it is the only route by which a national decree reaches the time zone database at all. A government announces that it will abolish daylight saving time or shift its standard offset; someone posts the official notice, often with a translation; a maintainer writes the change into the rule files; and a release follows. A copyright claim against the project in 2011 briefly took the files and the list offline, but the claim was withdrawn and the database has been hosted under IANA stewardship ever since.
How a Change Reaches Your Devices
- Announcement: a national government or territory publishes a decree changing its clocks.
- Submission: a contributor reports it to the mailing list with the source document.
- Release: a new tzdata version ships, versioned by year and letter — 2023a, 2023b, 2024a and so on.
- Distribution: operating systems, language runtimes and browsers pull the release into their own updates.
- Installation: your device applies the update, usually without anyone noticing.
The weak link is the last two steps. A device that stopped receiving updates years ago is running an old copy of the tz database, and it will confidently display the wrong local time for any region that has changed its clocks since.
How Are Time Zones Named?
Zone identifiers follow an Area/Location pattern: a continent or ocean, a slash, then a representative place. America/New_York, Asia/Kolkata and Pacific/Auckland are typical. The location is normally a large city inside the zone rather than the country itself.
- Area: one of Africa, America, Antarctica, Arctic, Asia, Atlantic, Australia, Europe, Indian or Pacific.
- Location: usually the most populous city whose clock history matches the zone, so that the name stays meaningful to people who live there.
- Cities rather than countries: states merge, split and rename far more often than cities do, and one country can hold several zones, so city names age better.
- Punctuation: spaces become underscores and diacritics are dropped, which is why New York appears as New_York and São Paulo as Sao_Paulo.
- Aliases: retired names are kept as backward links, so Asia/Calcutta still resolves correctly to Asia/Kolkata rather than breaking old records.
There is one notorious trap. The Etc/GMT identifiers invert their signs to follow the POSIX convention, so Etc/GMT+5 means five hours behind Coordinated Universal Time, not ahead of it. Anyone reading a raw offset should check it against a proper UTC offsets table before trusting the sign.
How Often Does the Time Zone Database Change?
Several times in a typical year. Releases appear whenever a government alters its clocks, and governments do this more often, and with less notice, than most people assume — sometimes only days before the change takes effect.
Some tz database releases are administrative, correcting a historical date or merging two zones whose rules have been identical since 1970. Others are urgent, because a country has announced on a Thursday that daylight saving time ends on the Sunday. The pattern of these amendments is the subject of historical time zone changes, which looks at the countries that have moved their clocks for political reasons.
Why Software Depends on the IANA Time Zone Database
Because no program can calculate local time from first principles. There is no formula that turns a latitude and longitude into an offset; the answer is a political fact, and the tz database is where that fact is written down.
- Operating systems: Linux, macOS, Android and the BSDs read the compiled tzdata files directly for every local timestamp they render.
- Language runtimes: Java, Python, PHP, Ruby and Go all expose zone identifiers taken from the same source, which is why the same string works across them.
- Browsers: the Internationalization API in every major browser resolves zone identifiers through the same data, so a web page and the host system agree.
- Databases: MySQL and PostgreSQL load the tables so that queries can convert stored instants into local wall time.
The practical consequence for anyone building software is that a stored UTC offset is not a time zone. An offset is a snapshot; a zone identifier is a rule that survives the next change. That distinction, along with the traps around daylight saving gaps, is covered in detail in time zones for developers.
What the Time Zone Database Does Not Do
The IANA time zone database does not define UTC, adjudicate borders or decide which abbreviation a country uses in speech. It ships a list of leap seconds for reference, but those are determined by international earth-rotation monitoring, not by its maintainers. It takes no view on disputed territory beyond recording what clocks there actually show.
It also cannot make abbreviations unambiguous. The files contain strings such as IST and CST because those are what people write, not because they identify anything uniquely — a problem explored in time zone abbreviations. When precision matters, the zone identifier is the only safe currency, and the time zone converter works from those identifiers rather than from labels.
Conclusion
The IANA time zone database is the quiet infrastructure behind correct local time everywhere: a volunteer-maintained, publicly argued record of every offset and daylight saving rule since 1970, published as tzdata releases and consumed by essentially every platform. Use its zone identifiers rather than offsets or abbreviations, keep your copy current, and most time bugs never appear. Browse the full set of zones and their live local times in the time zone browser, or start from the timezones.now homepage.