The IANA Time Zone Database
The IANA Time Zone Database (often abbreviated as "tz database" or "tzdata") is a maintained, version-controlled database of every named time zone in the world, including the historical record of every offset and daylight-saving rule each zone has ever had. It is used by nearly every modern operating system and programming language as the source of truth for time-zone information.
How the database is structured
Each zone is identified by a Continent/City name, for example America/New_York, Europe/Berlin or Asia/Singapore. Inside the database, each name maps to a sequence of "transitions": pairs of (UTC instant, new offset) that describe how local time has changed in that zone over the years. When a calendar app needs to render a meeting in America/New_York on a particular date, it walks down the list of transitions to find the offset in effect on that date and applies it to the underlying UTC time.
The database also stores zone aliases (for example, US/Eastern is an alias for America/New_York) and a separate "country code → primary zone" lookup that is used by the time-zone pickers you see in operating system installers. ZoneShift uses the canonical zone names throughout to avoid the ambiguity that aliases sometimes introduce.
Release cadence
The IANA database is updated several times a year, often on short notice in response to political decisions about daylight saving. A typical release contains a handful of zone changes, plus corrections to historical records that have been uncovered by researchers. Operating system vendors usually pick up new releases within a few weeks; container images and embedded systems can lag by months or years if nobody is watching, which is a common cause of subtle scheduling bugs in older deployments.
ZoneShift uses PHP's bundled timezonedb, which is updated alongside PHP itself, so the offsets and DST transitions you see here are accurate as of the version of PHP this site is running on. We rebuild the static city dataset periodically to pick up changes; you can see the build timestamp on the About page.
For developers
If you write software that handles times, the cardinal rule is: store moments as UTC instants, and store the user's intended display zone as a separate IANA identifier. Never store an offset directly: the offset for a given zone changes over the year as DST begins and ends, and a stored offset will be silently wrong six months later. Every modern language has a binding for the IANA database — Python's zoneinfo, Java's java.time.ZoneId, PHP's DateTimeZone, JavaScript's Intl.DateTimeFormat — use them rather than rolling your own offset arithmetic.