The IANA time zone database
Almost every correct time zone conversion in the world traces back to one shared dataset. It records not just what the offsets are, but what they have been, and it changes several times a year.
One database behind every clock
The IANA time zone database — also called the tz database, tzdata, zoneinfo, or the Olson database after its original coordinator Arthur David Olson — is a public dataset of every civil time zone rule that the maintainers have been able to document.
It is used by Linux and other Unix systems, Java, Python, browsers, the ICU internationalisation libraries, and effectively every programming language that can convert between zones. When your phone gets the time right after you land, this is why.
Crucially, it is historical as well as current. The database aims to be correct for every zone since 1970, so converting a timestamp from 1985 applies the rules that were actually in force then rather than today's.
Why identifiers look like Europe/Copenhagen
Identifiers follow an Area/Location convention, where the area is a continent or ocean and the location is usually the largest city in the region that shares a rule set.
Cities are used rather than countries on purpose. Country borders and names change, and a single country can contain several zones, so naming a zone after a city keeps the identifier stable and politically neutral.
Old identifiers are kept as aliases rather than deleted, so Asia/Calcutta still resolves to Asia/Kolkata. One trap worth knowing: identifiers in the Etc/GMT+N family have inverted signs, so Etc/GMT+5 is UTC−05:00.
The rules keep changing
Governments change time zone rules with little notice — adopting or abandoning daylight saving, shifting a standard offset, or splitting a region. The database is updated several times a year in response, and each release is given a version like 2026a.
This is why time zone handling cannot be hard-coded. A system that shipped its rules two years ago will quietly produce wrong answers for any region that has changed since.
It also means future dates are predictions, not guarantees. A meeting scheduled eighteen months out is converted using the rules currently on the books, and those rules can change before the date arrives.
Try the tools
Frequently asked questions
- Why not just store a UTC offset?
- An offset describes a single moment, not a place. Storing Europe/Copenhagen lets a system work out the correct offset for any date, including across daylight saving transitions and past rule changes. Storing UTC+01:00 loses that.
- How often does the database change?
- Typically a handful of releases per year, sometimes more when several governments make changes at once. Updates can arrive only weeks before they take effect, which is why keeping the data current matters.
- Is data before 1970 reliable?
- It is included where it could be researched, but only data from 1970 onwards is intended to be correct. Earlier entries are best-effort and should not be relied on for precise historical work.
- What does NowZones use?
- Every time and conversion on this site is computed from the IANA database through well-tested date libraries, so city pages reflect the current published rules for that zone including daylight saving.