Why use IANA identifiers instead of fixed UTC offsets?

An identifier like Europe/London encodes the full history and future rules of a region, including daylight saving transitions. A fixed offset like +00:00 cannot follow these rules, so dates computed across a DST boundary would be wrong.

What does the offset shown here represent?

It is the zone's standard-time (winter) base offset from UTC. Zones marked as observing DST shift by an extra hour during their summer, so the live offset can differ from the value listed here for part of the year.

Why are some identifiers named after cities?

The tz database uses the largest representative city of a zone (Area/City) because city names are stable and unambiguous, whereas political timezone names change. Asia/Kolkata covers all of India even though India has one zone.

What is the difference between UTC and Etc/GMT?

UTC is the canonical zero-offset identifier. The Etc/GMT entries are fixed-offset zones with inverted signs (Etc/GMT-5 is UTC+5), kept for legacy POSIX compatibility. Prefer UTC or a real Area/City zone in new code.

Do offsets like +05:30 and +05:45 really exist?

Yes. India uses UTC+05:30 (Asia/Kolkata) and Nepal uses UTC+05:45 (Asia/Kathmandu). Several zones use half-hour or quarter-hour offsets, which is exactly why hardcoding whole-hour offsets breaks.

What is the IANA Time Zone Identifiers?

Searchable IANA tz database reference: canonical Area/Location identifiers such as Europe/London and Asia/Yerevan, their standard-time UTC offset, whether they observe DST, and the country they belong to. It runs free in your browser on Gera Tools, with nothing uploaded.

IANA Time Zone Identifiers

Name: IANA Time Zone Identifiers
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

IANA time zone identifier reference

The IANA tz database (also called the Olson or zoneinfo database) is the authoritative source for time zone rules used by operating systems and most programming languages. Each zone has a canonical identifier in Area/Location form, like Europe/London or Asia/Yerevan, that captures the region’s full history of offsets and daylight saving transitions. This reference lets you search those identifiers by city, country or offset.

How it works

An identifier names a region whose local time has followed the same rules since 1970. To find the wall-clock time you take UTC, apply the zone’s current offset, and add an hour during daylight saving if the zone observes it:

local = UTC + base_offset (+1h while DST is in effect)

The database tracks every transition, so a library given America/New_York knows it was UTC-5 in winter and UTC-4 in summer, and exactly when each switch happened. The standard-time offset shown here is the base (winter) value; zones flagged as observing DST move forward in their local summer.

Identifiers use a stable representative city, not a political name, because cities rarely rename while timezone politics change often. Some zones use non-whole-hour offsets — India is +05:30, Nepal +05:45 — which is why you must rely on identifiers rather than assuming whole-hour offsets.

Why identifiers beat raw UTC offsets

Storing +01:00 instead of Europe/Paris seems simpler until a government changes DST rules — then every record carrying a raw offset becomes wrong for dates after the rule change. The identifier delegates all that logic to the tz database: the library receives the name, looks up which rules apply at a given moment, and returns the correct local time.

This matters most for:

Scheduled jobs and calendar events. A meeting at 09:00 Europe/London stays at 09:00 wall-clock even when clocks change; +00:00 silently shifts it an hour.
User profile storage. Storing a user’s city-based identifier lets you localise notifications and timestamps correctly for their whole history.
Historical timestamp display. What was the local time when this event was logged at epoch 1234567890? An identifier knows the rules that applied at that exact moment; a raw offset does not.

Non-whole-hour offsets: the zones you must not miss

Many developers assume all offsets are whole hours. These zones break that assumption:

Identifier	UTC offset
Asia/Kolkata (India)	+05:30
Asia/Kathmandu (Nepal)	+05:45
Asia/Yangon (Myanmar)	+06:30
Pacific/Marquesas	-09:30
Australia/Lord_Howe	+10:30 / +11:00 (DST)

If your scheduling code assumes offset % 60 === 0, it will miscalculate times for millions of people.

Tips and notes

Always store and schedule using an identifier (Asia/Tokyo), never a raw offset, so DST and historical changes are handled for you.
UTC is the right choice for timestamps and logs; convert to a user’s zone only at display time.
Northern and Southern Hemisphere DST run in opposite halves of the year — Australia/Sydney springs forward when Europe/Berlin falls back.
Treat Etc/GMT±N as legacy: the sign is inverted (Etc/GMT-5 is UTC+5) and they never observe DST.
Use this reference to copy the exact canonical string before pasting it into a database column or config file — a single character difference (Americas/New_York vs America/New_York) causes a silent failure in most libraries.