Time Zones and the IANA Database

A time zone identifier like America/New_York or Asia/Shanghai is not a display label — it is the name of a complete rule set. It records, for one region, every offset from UTC that has been in force and the exact dates the rules changed: when daylight saving starts and stops, and when the underlying standard offset itself shifted. The city in the name is not there to be shown to a user. It anchors that history to a place whose clocks have followed one consistent sequence of laws.

This is why software that takes time seriously stores a zone identifier rather than a bare offset. “UTC-5” tells you where the clock sits at one instant; America/New_York tells you where it will sit at any instant, past or future, by applying the right rule for that date. The database behind those identifiers is the IANA time zone database, and understanding what it does explains a surprising number of everyday oddities.

The Area/City naming scheme

Identifiers follow an Area/City pattern: a broad area — usually a continent such as America, Europe, Asia, or Africa — followed by a representative city. America/New_York, Asia/Shanghai, Europe/London, Africa/Cairo. The city is chosen as a stable anchor for the rules, not because it is the largest or the capital. Asia/Shanghai, for instance, governs all of mainland China even though the country spans a geographic width that would naturally cover several zones, because China runs on a single official time. The name marks the rule history, not a claim about geography.

What the tz database actually stores

The tz database — also called tzdata or zoneinfo, and maintained under the umbrella of IANA — is a decades-long effort to record civil time accurately. It was founded by Arthur David Olson (which is why it is sometimes still called the Olson database) and has long been edited by Paul Eggert. Its coverage reaches back to 1970 with full fidelity, and often earlier, capturing the historical changes that make honest date math possible.

Because it stores history rather than a single current offset, it can answer questions the clock on your wall cannot. What was the local time in a given city on a specific date twenty years ago, before that country abolished daylight saving or moved its standard offset? The database knows, because it recorded the rule that was in force then rather than projecting today’s rule backwards.

Abbreviations are ambiguous; offsets are not zones

Two habits cause most real-world confusion, and the tz database is designed to sidestep both.

• Abbreviations collide. “CST” is not one thing. It is US Central Standard Time (UTC-6), China Standard Time (UTC+8), and Cuba Standard Time (UTC-5), among others. An email that says “3 PM CST” is genuinely ambiguous without knowing which country the sender meant. A full identifier like America/Chicago or Asia/Shanghai carries no such ambiguity.
• An offset is not a zone. “UTC-5” describes an offset at one moment. America/New_York is a zone that alternates between UTC-5 in winter and UTC-4 during daylight saving. Storing the offset throws away the rule that decides which one applies on a future date; storing the zone keeps it.

The reason offsets and zones diverge at all is daylight saving, and the mechanics of those 23- and 25-hour transition days are covered in the companion guide on daylight saving time and date math.

Zones change, and updates ship several times a year

The database is not frozen. Countries change their minds: they abolish daylight saving, shift a standard offset, or split and merge zones. When they do, a new release of tzdata goes out — this happens several times a year, on no fixed calendar, driven by whenever a government announces a change. Zones also get renamed or merged over time as rules that were once distinct converge, with the old names kept as aliases so existing data keeps resolving. Keeping the database current is what lets a calendar entry made today still be correct after a country changes its rules next year.

Why AskTheDate puts the zone in the URL

AskTheDate embeds an IANA zone in every URL — one of 72 curated zones — because the same wall-clock question genuinely has different answers in different zones. Ask “what day is it?” near midnight and the honest reply depends entirely on where you are standing: it can already be tomorrow in Asia/Shanghai while it is still today in America/New_York. Baking the zone into the address makes each answer unambiguous, shareable, and reproducible — the link itself records which clock the answer was computed against, so it reads the same for whoever opens it.

You can see the divergence directly. The New York time page and the Shanghai time page will, for much of each day, disagree about the calendar date — not a bug, but the whole reason zones exist.

Try it

Open the New York time-zone converter and convert a late-evening New York time into Asia/Shanghai. Watch the date roll over to the next day — the clearest one-glance demonstration of why a zone, not an offset, is the thing worth storing.