Guide

The IANA time zone database: what it is and why your meetings depend on it.

Every correct time conversion you've ever seen — on your phone, laptop, or this planner — traces back to one volunteer-maintained dataset. Here's how it works and why anything built without it quietly goes wrong.

Updated November 9, 2026 · Reviewed by The Vibing Dev.

What the tz database actually is

The IANA time zone database (often called "tz" or "zoneinfo") is the global standard record of civil timekeeping: which offset every region observes, when daylight saving starts and ends, and how all of that has changed historically. It is stewarded by IANA with a small group of maintainers, ships inside virtually every operating system and browser, and is updated in several releases per year as governments change their rules.

Each entry is keyed by a zone identifier like America/New_York — a region whose clocks have agreed since 1970 — rather than by an abbreviation. That one design decision is what makes the whole system reliable.

Why abbreviations fail: one code, many clocks

Abbreviations like CST or IST look precise and mean almost nothing. The same three letters routinely denote zones hours apart — and they say nothing about DST:

Rule of thumb: cities and IANA keys in, abbreviations never. "3 PM Chicago" is unambiguous. "3 PM CST" is a coin flip. Our conversion guide goes deeper on getting this right every time.

Time is political: real changes the database absorbs

Governments move clocks for politics, energy, and religion — often with weeks of notice. A hardcoded offset table can't survive this; the tz database absorbs each change in a new release:

• Samoa (2011): skipped Friday, December 30 entirely to jump west of the dateline — a whole calendar day vanished by decree
• Turkey (2016): stayed on summer time permanently (UTC+3), cancelling the fall-back weeks before it was due
• Morocco: shifts clocks four times a year around Ramadan — the only country on a religious DST rhythm
• North Korea (2015–2018): invented UTC+8:30 "Pyongyang Time", then abandoned it three years later
• Chile: has repeatedly moved its DST start and end dates, including same-season reversals

Any converter with baked-in offsets is wrong the moment a change like these ships. Anything reading live tz data — your OS, your browser, this planner — picks it up with the next update.

Fractional offsets: the half hours that break naive math

Not every zone sits on a whole hour. The database carries these exactly, while "UTC±N" mental math rounds them away:

• India (UTC+5:30), Nepal (UTC+5:45) — permanent fractional offsets
• Chatham Islands (UTC+12:45 / +13:45) — 45-minute DST shift, the world's oddest
• Lord Howe Island (UTC+10:30 / +11:00) — a 30-minute spring forward instead of an hour
• Eucla, Australia (UTC+8:45) — an unofficial zone observed by a few hundred people, tracked anyway

How this planner uses the database (and why it never goes stale)

This site performs zero time math of its own. Every conversion runs through your browser's native Intl.DateTimeFormat API against the full IANA dataset — the exact same source your operating system uses. Concretely, that means:

• No hardcoded offsets anywhere — nothing to rot when governments change rules
• Conversions are computed for the meeting date you pick, so the March and October gap weeks resolve correctly
• Fractional offsets, historical rules, and day-boundary crossings come free with the database
• Share links encode the date, so recipients get the same correct answer on any device

What this means for your scheduling

• Prefer tools over tables. A static "world clock chart" is a snapshot; a tz-backed planner is a live instrument. Use the latter for anything dated in the future.
• Distrust fixed-offset advice. "London is always 5 hours ahead of New York" is false during the spring and autumn mismatch weeks — see the 2027 gap weeks.
• Audit recurring meetings at release boundaries — early March and late October, when Northern-hemisphere rules flip.