IANA Time Zone Database (tzdb), Olson IDs & UTC Offsets

The IANA Time Zone Database (frequently referred to as tzdb, the Olson database, or the zoneinfo database), founded by Arthur David Olson and maintained by the Internet Assigned Numbers Authority (IANA) and Paul Eggert, is the reference standard for representing time zones, daylight saving rules, and temporal offsets across global computer systems.

Convert between global time zones, inspect UTC offsets, and calculate team meeting overlap with our free Timezone Converter & Meeting Planner tool.

---

Anatomy of an IANA Timezone Identifier

IANA timezone identifiers follow a structured hierarchical naming pattern:

$$\text{Area}/\text{Location}$$

• Area: The continent or ocean basin (e.g., America, Europe, Asia, Africa, Australia, Pacific, Atlantic, Indian, Antarctica, or Etc).
• Location: The most populous principal metropolitan city or representative location within the temporal region (e.g., New_York, London, Tokyo, Kolkata, Sao_Paulo).

America/New_York
└──┬──┘ └───┬──┘
   │        └── Principal City / Reference Settlement
   └─────────── Geographic Continent or Ocean Region

---

IANA Identifiers vs. Static Offsets vs. Abbreviations

Understanding the difference between these three concepts is essential for reliable software architecture:

Property	IANA Identifier (Area/Location)	Static Numerical Offset (+HH:MM)	Seasonal Abbreviation (EST/EDT)
Example	America/New_York	-05:00	EDT (Eastern Daylight Time)
Daylight Saving Awareness	Dynamic (encapsulates historical & future DST transition rules)	Static (constant offset, no shift)	Ambiguous (changes with season, shared across multiple countries)
Uniqueness	Globally unique canonical key	Multiple disparate zones share the same offset	Non-unique (e.g., CST is China Standard Time, Central Standard Time US, Cuba Standard Time)
Future Date Scheduling	Safe (applies future governmental rule changes)	Unsafe (risks 1-hour drift if DST shifts before date)	Unsafe (context-dependent)
Standard Usage	Database user profile storage, calendar events, cron jobs	Wire protocol timestamps, ISO 8601 strings	UI presentation text

---

Fractional & Non-Hour UTC Offsets

While many global zones operate on whole-hour offsets relative to UTC, several jurisdictions observe fractional 30-minute or 45-minute offsets:

Jurisdiction	Canonical IANA Identifier	Standard UTC Offset	Notes
India	Asia/Kolkata	UTC+05:30	Indian Standard Time (IST), no DST
Sri Lanka	Asia/Colombo	UTC+05:30	Sri Lanka Standard Time (SLST), aligned with IST
Nepal	Asia/Kathmandu	UTC+05:45	Nepal Time (NPT), 15 minutes ahead of IST
Iran	Asia/Tehran	UTC+03:30	Iran Standard Time (IRST), abolished DST in 2022
Afghanistan	Asia/Kabul	UTC+04:30	Afghanistan Time (AFT), no DST
Myanmar / Cocos	Asia/Yangon	UTC+06:30	Myanmar Time (MMT), no DST
South Australia	Australia/Adelaide	UTC+09:30 / UTC+10:30	Observes Southern Hemisphere Daylight Saving Time
Northern Territory	Australia/Darwin	UTC+09:30	Australian Central Standard Time (ACST), no DST
Lord Howe Island	Australia/Lord_Howe	UTC+10:30 / UTC+11:00	Unique 30-minute DST shift
Chatham Islands	Pacific/Chatham	UTC+12:45 / UTC+13:45	New Zealand territory with 45-minute offset & DST

---

Code Examples: Working with IANA Timezones

Modern JavaScript / TypeScript (Intl.DateTimeFormat)

// Format an arbitrary UTC instant into a specific IANA timezone
export function formatInTimezone(date: Date, timeZone: string): string {
  return new Intl.DateTimeFormat('en-US', {
    timeZone,
    dateStyle: 'full',
    timeStyle: 'long',
  }).format(date);
}

const meetingTime = new Date('2026-09-06T14:30:00Z');
console.log(formatInTimezone(meetingTime, 'America/New_York'));
// Output: "Sunday, September 6, 2026 at 10:30:00 AM EDT"
console.log(formatInTimezone(meetingTime, 'Asia/Kolkata'));
// Output: "Sunday, September 6, 2026 at 8:00:00 PM GMT+5:30"

Python 3 (zoneinfo module)

from datetime import datetime, timezone
from zoneinfo import ZoneInfo

# Instant in UTC
utc_now = datetime.now(timezone.utc)

# Convert to targeted IANA timezone
tokyo_time = utc_now.astimezone(ZoneInfo("Asia/Tokyo"))
london_time = utc_now.astimezone(ZoneInfo("Europe/London"))

print(f"Tokyo: {tokyo_time.strftime('%Y-%m-%d %H:%M:%S %Z%z')}")
print(f"London: {london_time.strftime('%Y-%m-%d %H:%M:%S %Z%z')}")

Go (time package)

package main

import (
	"fmt"
	"time"
)

func main() {
	now := time.Now().UTC()

	locNY, _ := time.LoadLocation("America/New_York")
	locSyd, _ := time.LoadLocation("Australia/Sydney")

	fmt.Println("New York:", now.In(locNY).Format(time.RFC3339))
	fmt.Println("Sydney:  ", now.In(locSyd).Format(time.RFC3339))
}

SQL (PostgreSQL AT TIME ZONE)

-- Convert UTC timestamp to user's localized IANA timezone
SELECT created_at AT TIME ZONE 'America/Los_Angeles' AS pacific_time
FROM user_sessions
WHERE user_id = 42;

---

Engineering Best Practices

1. Store User Preferences as IANA Keys: In user profile schemas, store "America/New_York" or "Europe/Berlin"—never a static string like "EST" or "-05:00". When Daylight Saving Time changes, the application automatically displays correct local times.
2. Persist Timestamps in UTC: Store server events and audit logs in UTC Unix timestamps or ISO 8601 format (TIMESTAMPTZ in PostgreSQL).
3. Keep tzdb Updated: Operating systems and container images (e.g. tzdata package on Debian/Alpine) must be kept up to date to receive geopolitical timezone changes enacted by governments.
4. Beware the 2:00 AM DST Trap: Do not schedule critical cron jobs between 01:00 AM and 03:00 AM local time. Always run recurring background infrastructure in UTC.