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

Every time your phone correctly shows the local time after you land in a new country, or a website correctly schedules a meeting across three continents accounting for daylight saving time, there’s a good chance a single shared piece of infrastructure is doing the actual work behind the scenes: the IANA Time Zone Database, often just called “the tz database” or “tzdata.”

Who actually maintains it

The tz database is not run by a government or a single company. It’s a volunteer-maintained public domain dataset, coordinated through a mailing list of time zone experts, historians, and software engineers, and distributed under the stewardship of the Internet Assigned Numbers Authority (IANA) — the same organization that manages other core internet infrastructure identifiers like domain name parameters and protocol numbers.

The project traces back to work started in the 1980s by Arthur David Olson and Paul Eggert, and it’s sometimes still called the “Olson database” for that reason. What makes it valuable isn’t just the current UTC offset for each region — plenty of sources can tell you that — it’s the historical record: every time zone change, every daylight saving time rule, and every government decision to shift a country’s offset, going back over a century in many cases, plus the rules needed to project future transitions like scheduled DST dates.

The naming convention: Area/Location, not just an offset

Instead of naming zones by their UTC offset (which would break the moment a country changes its offset or DST policy), the tz database names zones after a representative location, in the format Area/Location — for example America/New_York, Europe/London, Asia/Shanghai, or Australia/Sydney.

This convention exists specifically so that a single identifier can represent a place’s entire history of civil time rules rather than a single fixed offset. America/New_York doesn’t just mean “UTC-5” — it encodes the full rule set for how New York’s clocks have moved and will move, including every DST transition. That’s why software that wants to correctly compute “what time is it in New York” a year from now, accounting for a DST switch that hasn’t happened yet, needs the full zone identifier rather than a raw offset number.

The “representative location” doesn’t have to be the largest city in a region — it’s chosen because that location’s historical clock changes are representative of the whole area covered by the zone. That’s why, for instance, America/Chicago covers the entire US Central time zone rather than there being a separate identifier for every city within it: all those cities have shared exactly the same offset and DST history.

Some entries also carry qualifiers to disambiguate similarly named or historically distinct areas, such as America/Indiana/Indianapolis, reflecting the fact that different parts of Indiana observed different DST rules for years before the state standardized.

How often it updates

The tz database is not a “set once” file. It’s updated whenever a government somewhere in the world changes a time zone rule — which happens more often than most people expect. A country might extend or shorten its daylight saving time window, a region might merge into a neighboring time zone, or a scheduled future DST transition might get postponed by new legislation. Updates are released as new versions (identified by a year and letter, like 2025b) whenever such a change is confirmed, sometimes several times in a single year.

This is why operating systems, browsers, and programming language runtimes need a mechanism to update their bundled copy of the tz database periodically — an app that ships with a tz database snapshot from several years ago can silently compute the wrong local time for any region whose rules changed since that snapshot was taken, even though the code itself never changed.

Backward-compatible aliases

Because software has depended on the tz database for decades, it maintains a set of legacy aliases alongside the modern Area/Location names, so that old code referencing an older identifier doesn’t break. Names like US/Eastern or US/Pacific still resolve correctly — they’re kept as aliases pointing at the current canonical identifiers (America/New_York, America/Los_Angeles) rather than being deleted outright when the naming convention was standardized. The database also ships supporting reference tables, such as one mapping ISO country codes to their associated time zones, which is what powers the country-and-city dropdown pickers you see in operating system settings and many web applications — letting an app show “United States” and then list only the zone identifiers that are actually relevant to it, rather than all several hundred entries in the full database.

Where the data actually lives on your machine

On most Linux and macOS systems, the compiled tz database ships as a set of binary files under a system directory (traditionally /usr/share/zoneinfo), one file per zone identifier, and the operating system’s date and time libraries read directly from those files. Windows historically maintained its own separate, differently structured time zone data rather than using tzdata files directly, though modern Windows versions and cross-platform runtimes increasingly rely on tzdata (or a mapping to it) as well, particularly for anything running in a browser or a cross-platform application framework. Programming language ecosystems generally bundle their own copy of tzdata inside the language runtime or a dedicated package, specifically so that date and time libraries don’t have to depend on whatever version happens to be installed at the operating-system level, which could be outdated or missing entirely on some deployment targets. That bundling is also why keeping a language runtime or a browser reasonably up to date matters for time zone accuracy — an old runtime carries an old, un-updated snapshot of the rules.

How your browser uses it

Modern browsers expose the tz database through the JavaScript Intl object, specifically APIs like Intl.DateTimeFormat and the underlying ECMAScript Temporal proposal that builds on it. When you pass an IANA zone identifier like Asia/Tokyo to these APIs, the browser looks up that zone’s full historical and current rule set from its bundled tz database and computes the correct local time, correctly handling any DST transition automatically — no manual offset math required, and no risk of forgetting that a particular country doesn’t observe DST at all.

This is also why time zone tools that let you type a city name and get an accurate local time, rather than a rough “UTC+8” style offset, are relying on the same underlying data, and why two different apps built this way will always agree with each other down to the minute, even across a DST transition, since they’re ultimately reading the same authoritative rule set rather than two independently maintained offset tables that could easily drift out of sync with one another: matching your input to an IANA identifier and letting the platform’s Intl implementation do the conversion. Our time zone converter works exactly this way — every city in it maps to an IANA zone identifier, so daylight saving time and historical rule quirks are handled the same way your browser handles them natively, rather than through a hardcoded offset table that would silently go stale. If you’re curious how this plays out for time zones that don’t fit the usual whole-hour pattern, our article on half-hour and 45-minute time zones covers a few of the more unusual entries in the database.