What is an IANA timezone?

An IANA timezone is a named entry in the IANA Time Zone Database (also called the tz database or Olson database), such as America/New_York or Europe/London. Each entry encodes the full history of UTC offsets and DST rules for that region.

How does an IANA timezone differ from a UTC offset?

A UTC offset like +05:30 only tells you the current difference from UTC; it carries no information about DST transitions or historical rule changes. An IANA timezone like Asia/Kolkata encodes all past and future rule changes, enabling correct date arithmetic across DST boundaries.

Why should I store IANA timezones instead of UTC offsets in my database?

UTC offsets change twice a year for DST regions, and governments occasionally change them permanently. Storing an IANA timezone name lets your application recompute the correct local time even after rules change, whereas a stored offset silently becomes wrong.

How often does the IANA timezone database change?

Several times a year. Countries adjust DST rules or switch UTC offsets with little notice — sometimes weeks in advance. Operating systems, browsers, and server runtimes ship tz database updates to keep local time conversions accurate.

Glossary

IANA timezone

The reference database for time zone rules

By Buğra SözeriPublished May 14, 2026Updated May 31, 2026

An IANA timezone is a canonical identifier like Europe/London, America/New_York, or Asia/Tokyofrom the IANA Time Zone Database (also called “tzdata” or “Olson database” after its original maintainer, Arthur David Olson).

Each entry captures every historical and current rule for UTC offset and daylight-saving behaviour for a region. “Europe/London” encodes: GMT (UTC+0) in winter, BST (UTC+1) in summer, the precise DST transition dates, and historical pre-1971 quirks. Pasting a date and zone into any modern programming language returns the correct offset because tzdata is built into the OS.

The naming convention is Region/City, where Region is one of Africa, America, Antarctica, Asia, Atlantic, Australia, Europe, Indian, Pacific, plus the special UTC, Etc/GMT, etc. City is a canonical city within the zone — Istanbul represents all of Turkey, New_York represents the US Eastern timezone, and so on.

Convertitive’s timezone converterworks against the browser’s OS-level tzdata via Intl.DateTimeFormat, so DST transitions and offset changes are always current without Convertitive having to ship updates.

Worked example

You’re scheduling a recurring weekly team standup at “Tuesdays 09:00 New York time” for attendees in NYC, London, and Tokyo. Store the meeting as { rrule: "FREQ=WEEKLY;BYDAY=TU", time: "09:00", tz: "America/New_York" }. The London attendee’s calendar resolves each occurrence: in January, NY is on EST (UTC−5) and London on GMT (UTC+0), so meeting is 14:00 London. In March (after US DST starts but before EU DST starts), NY is on EDT (UTC−4) and London on GMT, so meeting is 13:00 London — moved an hour earlier. In June, both on summer time, NY EDT (UTC−4) and London BST (UTC+1), so meeting is 14:00 London again. Tokyo (UTC+9, no DST) sees the meeting shift between 22:00 and 23:00 depending on the season. Now imagine the team had stored the meeting as “14:00 UTC” instead — the NY attendee would experience the meeting time drifting back and forth as DST shifted, and the “Tuesday 9 AM” convention would silently break twice a year.

When and why it matters

IANA timezones matter the moment a system processes dates across more than one user, more than one location, or more than one season. The mistake to avoid in storage is using fixed offsets — “Asia/Karachi” survives a future DST reintroduction; “UTC+5” doesn’t. The mistake to avoid in display is rendering timestamps without specifying the destination zone — a backend log showing “2026-05-22 14:30” with no zone tag is ambiguous and unsearchable. The mistake to avoid in business logic is performing “add 1 day” arithmetic in UTC instead of in local time around DST transitions — “next day same wall-clock time” can be 23 or 25 hours away in UTC depending on whether DST starts that night. Modern datetime libraries (JavaScript’s Temporal API, Python’s zoneinfo, Java’s java.time) handle this correctly when given IANA identifiers; older APIs (JavaScript’s native Date, moment.js without timezone plugin) silently produce wrong answers. Reference: RFC 6557 — Procedures for Maintaining the Time Zone Database.

The IANA tzdata release cycle:tzdata releases are versioned by year + lowercase letter — 2024a, 2024b, 2025a, and so on. Releases happen on demand, usually 4-8 times per year, whenever a government changes DST rules or a region’s timezone offset. Notable recent changes: Mexico abolished DST nationwide in 2022; Russia abandoned then restored permanent winter time across multiple revisions; Lebanon had a one-week delayed DST start in 2023 due to political dispute. Every OS picks up the changes through routine package updates — but IoT devices and old phones that don’t auto-update can drift, leading to the canonical “my alarm clock is an hour off” problem during the first week after a DST rule change.

Why never store offsets directly:the most common mistake in datetime code is storing “UTC+2” instead of Europe/Istanbul. The offset captures a point-in-time fact about the zone but not the rules. If Turkey reintroduces DST (it abolished DST in 2016, but rule changes are common in the region), every record with “UTC+2” becomes wrong overnight. Store the IANA zone identifier and let the lookup compute the correct offset for each timestamp. Related: UTC, leap second. Reference: IANA Time Zone Database.

Try the calculator

Pick any IANA zone (Europe/London, America/New_York, …) and convert a moment into it.

Open the timezone converter →

Frequently asked questions

What is an IANA timezone?: An IANA timezone is a named entry in the IANA Time Zone Database (also called the tz database or Olson database), such as America/New_York or Europe/London. Each entry encodes the full history of UTC offsets and DST rules for that region.
How does an IANA timezone differ from a UTC offset?: A UTC offset like +05:30 only tells you the current difference from UTC; it carries no information about DST transitions or historical rule changes. An IANA timezone like Asia/Kolkata encodes all past and future rule changes, enabling correct date arithmetic across DST boundaries.
Why should I store IANA timezones instead of UTC offsets in my database?: UTC offsets change twice a year for DST regions, and governments occasionally change them permanently. Storing an IANA timezone name lets your application recompute the correct local time even after rules change, whereas a stored offset silently becomes wrong.
How often does the IANA timezone database change?: Several times a year. Countries adjust DST rules or switch UTC offsets with little notice — sometimes weeks in advance. Operating systems, browsers, and server runtimes ship tz database updates to keep local time conversions accurate.

Published May 14, 2026 · Last reviewed May 31, 2026