IANA Time Zone Database
The standardized time zone system used by computers worldwide
What is the IANA Time Zone Database?
The IANA Time Zone Database (also called tzdata, zoneinfo, or the Olson database) is the authoritative source of time zone information for computer systems worldwide. Originally developed by Arthur David Olson in 1986, the database is now maintained by IANA (Internet Assigned Numbers Authority) and a community of contributors who track every time zone change announced by governments around the world.
The database contains all recognized time zone names, UTC offsets for every zone, historical time changes going back decades, daylight saving time rules, and time zone abbreviations. Unlike fixed-offset approaches, the IANA database captures the full history of a region's timekeeping decisions, including dates when countries switched from one offset to another or abolished DST entirely. This historical accuracy is essential for software that needs to accurately represent or convert past dates.
Why the IANA Database Matters
Time zone rules change frequently. Governments announce new DST dates, abolish seasonal clock changes, or shift to permanent offsets — sometimes with little notice. Without a regularly updated database, software quickly produces incorrect times. The IANA database solves this problem by providing a single, authoritative reference that is updated several times a year as new legislation is passed worldwide.
Using IANA time zones gives developers several key advantages:
- Accuracy — Official, government-verified data updated regularly
- Consistency — Identical results across all platforms and languages
- Historical correctness — Account for past time zone changes, critical for financial and legal systems
- Future-proof — Automatically incorporates upcoming DST changes when systems update their tzdata package
- Global coverage — Over 400 time zone entries covering every country and region
How Time Zone Data is Maintained
The tz database is a collaborative open-source project. Contributors — including government agencies, corporations, and individual volunteers — submit proposed changes when a country announces a time zone rule change. The maintainers review submissions, verify them against official government sources, and release updated versions of the database.
Updates are typically released in February, July, and October, though emergency patches can happen at any time. Major operating systems and programming language runtimes pull these updates through their regular package or system update cycles. For example, Linux distributions ship updated tzdata packages, Oracle releases patched JDK versions, and Apple rolls updates into macOS and iOS system updates.
IANA Time Zone Format Explained
IANA time zones use the naming convention Area/Location, where the area is typically a continent or ocean, and the location is a major city within that zone. This hierarchical format makes it easy to browse and organize the database. Examples:
America/New_York
Europe/London
Asia/Tokyo
Australia/Sydney
Pacific/HonoluluThe underscore in names like America/New_York replaces spaces — the format deliberately avoids special characters to ensure compatibility across all programming environments. Some zones use the Etc/ prefix for generic offsets (such as Etc/UTC), and a few legacy or special-case zones use different structures.
Common IANA Time Zone Identifiers
There are over 400 IANA time zone identifiers, but a handful cover most major population centers. Here are the most commonly used:
| IANA Identifier | Standard Offset | DST Offset | Region |
|---|---|---|---|
| America/New_York | UTC-5 (EST) | UTC-4 (EDT) | Eastern US & Canada |
| America/Los_Angeles | UTC-8 (PST) | UTC-7 (PDT) | Pacific US & Canada |
| America/Chicago | UTC-6 (CST) | UTC-5 (CDT) | Central US |
| America/Denver | UTC-7 (MST) | UTC-6 (MDT) | Mountain US |
| America/Sao_Paulo | UTC-3 (BRT) | — | Brazil |
| Europe/London | UTC+0 (GMT) | UTC+1 (BST) | UK & Ireland |
| Europe/Paris | UTC+1 (CET) | UTC+2 (CEST) | France |
| Europe/Berlin | UTC+1 (CET) | UTC+2 (CEST) | Germany |
| Europe/Moscow | UTC+3 (MSK) | — | Russia (Moscow) |
| Asia/Tokyo | UTC+9 (JST) | — | Japan |
| Asia/Shanghai | UTC+8 (CST) | — | China |
| Asia/Singapore | UTC+8 (SGT) | — | Singapore |
| Asia/Kolkata | UTC+5:30 (IST) | — | India |
| Australia/Sydney | UTC+10 (AEST) | UTC+11 (AEDT) | Eastern Australia |
| Pacific/Auckland | UTC+12 (NZST) | UTC+13 (NZDT) | New Zealand |
| Africa/Cairo | UTC+2 (EET) | — | Egypt |
Who Uses the IANA Database?
The IANA time zone database is the backbone of time zone handling across virtually all major computing platforms. If your software deals with dates and times, it almost certainly relies on tzdata under the hood:
- Linux — All major distributions (Ubuntu, Fedora, Debian, RHEL) ship the
tzdatapackage. The system-wide/usr/share/zoneinfodirectory provides IANA zones to all applications. - macOS and iOS — Apple maintains its own copy of the tz database, updated through macOS and iOS system updates. Core frameworks like Foundation and SwiftUI use these zones internally.
- Java — The
java.timeAPI (introduced in Java 8) uses the IANA database bundled in the JDK. Oracle and OpenJDK release patched versions when significant tzdata updates are available. - Python — The
zoneinfomodule (standard library since Python 3.9) and the third-partypytzlibrary both use the IANA database. On Linux, Python reads from the system's zoneinfo files; on Windows, it uses thetzdataPyPI package. - JavaScript / Node.js — While browsers use the operating system's time zone data, Node.js exposes IANA zones through the
Intl.DateTimeFormatAPI and libraries likeluxon. - Databases — PostgreSQL, MySQL, and other relational databases accept IANA time zone names in queries, converting them to UTC or local time as needed.
- Cloud and DevOps — Docker base images, CI/CD pipelines, and serverless functions all depend on an up-to-date tzdata package to handle scheduling correctly.
Frequently Asked Questions
What is the difference between IANA time zones and POSIX time zones?
POSIX time zones use string abbreviations like EST5EDT that describe current DST rules but cannot represent historical changes. IANA time zones use named identifiers like America/New_York that include the full history of a region's timekeeping. For any application that needs to handle past or future dates correctly, IANA zones are strongly preferred.
How often is the IANA database updated?
The database is typically updated three to four times per year, timed to coincide with announced government changes. Emergency updates may be released if a country makes an unexpected announcement. Your operating system or runtime pulls these updates through its regular update cycle, so keeping your system updated ensures you have the latest rules.
Can I use IANA time zone names in Windows?
Yes. Since Windows 10 version 1607 and Windows Server 2016, Windows supports IANA time zone names through the TimeZoneInfo.FindSystemTimeZoneById() API. Python's zoneinfo module also works on Windows by using the tzdata package from PyPI. Older Windows versions only support Microsoft's own time zone IDs (like Eastern Standard Time).
What happens if my tzdata package is out of date?
Outdated tzdata can cause your software to apply incorrect UTC offsets or DST rules, especially for dates near or after a recent government change. This can lead to meetings scheduled at wrong times, incorrect logging timestamps, or failed cron jobs. Keeping your system's tzdata package current prevents these issues.
Programming Example
// JavaScript
const now = new Date();
console.log(now.toLocaleTimeString('en-US', {
timeZone: 'America/New_York'
}));
// Python
from datetime import datetime
import pytz
tz = pytz.timezone('America/New_York')
print(datetime.now(tz))