The IANA time zone database, explained

By Niraj Kumar · Published October 28, 2026

When a browser converts 09:00 in Kathmandu to London time, or a phone moves its clock forward on the right Sunday, it is consulting the IANA time zone database, also called tzdata, the tz database or the Olson database after Arthur David Olson, who began it in the 1980s. It is a set of plain text files recording, for every region in the world, what the UTC offset has been at every moment since 1970, what the daylight saving rules are, and when each of those things changed. The time zone list on this site is a view of it; so is every city page.

Zones are named after cities

Entries are identified as Area/City: Europe/London, America/New_York, Asia/Kolkata, Australia/Lord_Howe. The city is the largest or best known in the region sharing that history of rules, and the name is a stable identifier rather than a description, which is why Kolkata stands for all of India and why the old spelling Asia/Calcutta survives as an alias. Names are chosen so they do not change when politics do: the database does not use country names, because borders move and countries split, and it does not use abbreviations, because they are ambiguous.

A region gets its own zone if its clocks have differed from its neighbours’ at any time since 1970. That is why the United States has America/Indiana/Indianapolis and seven other Indiana entries, and why Antarctica has a dozen: each records a distinct history. There are around 350 canonical zones and a few hundred aliases.

Why abbreviations are not identifiers

CST means Central Standard Time in North America, China Standard Time and Cuba Standard Time. IST is Indian, Israeli and Irish Standard Time. BST is British Summer Time and Bangladesh Standard Time. AST is Atlantic and Arabia. The database records abbreviations only as display labels, and for many zones it uses plain numeric ones such as +0545 because no English abbreviation is in real use. Software that lets a user pick “CST” from a list has no way to know which one was meant. The meeting guide is largely about the consequences.

What a rule looks like

Each zone has a sequence of periods, each with a standard offset and a reference to a set of named rules describing daylight saving: when it starts, when it ends, by how much, and from which year. Europe/London has used the “EU” rules since 1996, which say the last Sunday of March and October at 01:00 UTC. Before that it has its own rules going back to 1916, with oddities such as the double summer time of the war years and the 1968 to 1971 experiment with permanent summer time. The history is as complete as the maintainers can make it, and corrections to dates in the 1940s still arrive.

How often it changes

Governments change their minds, and the database follows them. Releases are named by year and letter, 2026a, 2026b and so on, and there are usually three to ten a year. Some record a planned change years ahead; others are hurried out when a country announces a change with a few weeks’ notice, as Egypt, Morocco, Turkey, Chile, Samoa, Fiji and several others have done in recent years. Paraguay abolished daylight saving in late 2024, and Kazakhstan merged its two zones into one the same year. Each such change makes every existing device wrong for that country until the device updates.

How the data reaches you

Operating systems ship a copy and update it through their normal updates. Browsers use the one in the operating system or bundle their own through ICU, the library that provides the Intl APIs; Node.js bundles its own too. Java keeps a copy in the runtime, with a separate updater tool. Python, Go and most languages read the system copy or a packaged one. The practical consequence is that the same question can get different answers on two machines if one has an older copy, and that a device that stops receiving updates, such as an old phone or an embedded controller, keeps applying stale rules indefinitely.

This site records nothing about zones itself. Every offset and every daylight saving date on it comes from the copy in the Node.js build that generated the pages and, for the live clocks, from the copy in your browser. The release the pages were built from is stated on the about page. If a government changed its rules last week, your browser may not know yet, and neither may this site.

The Etc zones and other oddities

The database includes Etc/UTC and a set of fixed-offset zones named Etc/GMT+n, whose signs are inverted from the usual convention for historical reasons: Etc/GMT+5 is five hours behind UTC. They have no daylight saving and should never be used for a real place. There are also a few zones for places with no permanent population, such as Antarctica/Troll, which jumps two hours between winter and summer, and Australia/Eucla for an unofficial +08:45 kept by a few hundred people.

Using it well

Store and transmit the zone name, never the offset or the abbreviation. Use a library that reads the database rather than one with hard-coded rules; in a browser that is Intl.DateTimeFormat with the timeZone option, which is what every tool here uses. Keep systems updated, and treat a date more than a year or so in the future as provisional, since the rules may change before it arrives. And when two systems disagree about a time, check which tzdata release each one has before looking for a bug.

The database is maintained by volunteers, coordinated by a small group at IANA, from newspaper reports, government gazettes and mailing-list correspondence. It is one of the clearest examples of critical infrastructure that nobody owns: airlines, banks, phone networks and every world clock run on it, and the next clock change anywhere is whatever its latest release says it is.