worldclock.tools

Developer & system utilities

IANA time zone explorer

The whole tz database, searchable. Find any IANA zone name and see its current offset and local time live — the canonical identifiers to reach for in code.

0 IANA zones · showing 0

No zone matches “”.

How to use the iana time zone explorer

  1. Search the zone list

    Browse or filter the IANA identifiers your browser knows about — several hundred names in Area/Location form.

  2. Inspect a zone

    See its current offset, whether it observes daylight saving, and when its clocks next change.

  3. Compare related zones

    Countries with several zones list them separately. Comparing them shows exactly where an internal boundary sits and how the offsets differ.

  4. Use the identifier

    Copy the canonical name — America/Argentina/Buenos_Aires, not ART — into your configuration or code.

What the IANA time zone database actually is

The IANA time zone database, also called tzdata or the Olson database, is the shared record of every civil time rule the world uses — current offsets, daylight-saving rules, and the full history of changes back to 1970 and often much earlier. It underpins essentially every operating system, browser and programming language, which is why your phone knows that Samoa skipped 30 December 2011 entirely.

Identifiers take the form Area/Location, such as Europe/Paris or America/Sao_Paulo, and each names a region that has shared the same rules since 1970. The city chosen is usually the largest in the region and is a label, not a claim about administrative boundaries. Zones split when regions diverge: America/Argentina has several entries because Argentine provinces once kept different clocks.

The database changes several times a year, because governments change their minds. Recent releases have handled Mexico abolishing daylight saving, Iran doing the same, Chile and Jordan shifting rules, and Egypt reinstating them. Each release gets a version like 2026a, and systems that are not updated will quietly compute the wrong local time after a rule changes.

There is also a set of Link entries — backwards-compatible aliases such as US/Eastern or Asia/Calcutta — kept so old configuration keeps working. They resolve to the canonical name (America/New_York, Asia/Kolkata), and new code should use the canonical form.

When you'd reach for it

Choosing a zone for a user profile

Pick the correct canonical identifier to store rather than an offset.

Auditing configuration

Check which zones your servers, containers and cron jobs are actually set to.

Investigating a wrong time

See whether a zone's rules changed recently and whether your system has the update.

Supporting a new market

Find the right zones for a country you are expanding into, including its internal splits.

Writing tests

Pick zones with awkward properties — half-hour offsets, no DST, southern-hemisphere rules — to test against.

Migrating from abbreviations

Map legacy codes onto canonical identifiers.

Questions & answers

Where does the list come from?
Directly from your browser's built-in Intl engine (Intl.supportedValuesOf('timeZone')), which ships the IANA tz database. No network request is made.
What is an IANA time zone name?
A canonical identifier like America/New_York or Asia/Kolkata, tied to a region's full history of offsets and daylight-saving rules — the reliable way to represent a zone in software.
Why do the offsets change over the year?
Because the offsets shown are live and reflect daylight saving. A zone like Europe/Paris reads UTC+1 in winter and UTC+2 in summer.