Timezone Reference Lookup

Find IANA timezone identifiers for any city or country

Search IANA (Olson) timezone identifiers like Europe/London and Asia/Tokyo, and see each zone's live current UTC offset and whether it is observing daylight saving time right now, computed in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is an IANA timezone identifier?

IANA timezone identifiers, also called Olson or tz database names, take the form Area/Location such as Europe/London or America/New_York. The location is a representative city for a region that shares the same offset and DST history, and these strings are the canonical way to specify a timezone in software.

What this tool is for

This reference helps you find the correct IANA timezone identifier for a city or region and immediately see what that zone’s UTC offset is right now. It is aimed at developers configuring servers, scheduling jobs, or storing user timezones, where the canonical Olson name matters more than a raw offset.

How it works

Each timezone is named Area/Location, where the location is a representative city that stands in for everywhere sharing the same offset and daylight-saving history. To compute the live offset, the tool asks your browser for the wall-clock time in the zone at this instant and subtracts UTC, which yields the current offset in minutes.

To determine daylight-saving status, it samples the offset in January and July. If the two differ, the zone observes DST, and the larger eastward offset corresponds to summer time. The current offset is then matched against those samples to report whether the zone is on summer time, on standard time, or never changes. This comparison works for both hemispheres because it never assumes which months are summer.

Practical use: finding the right identifier string

When you type “Tokyo” the identifier Asia/Tokyo appears. That exact string is what belongs in a database timezone column, a TZ environment variable on a server, or a dateTimeZone parameter in a scheduling API. The full form matters — Tokyo alone is not a valid IANA identifier and will fail silently in most libraries.

Common lookups that trip people up:

  • India — one zone, identifier Asia/Kolkata (not Bombay, not India). Offset UTC+05:30.
  • China — one zone, identifier Asia/Shanghai. China spans four geographic zones but uses one.
  • US East CoastAmerica/New_York, not US/Eastern (which is a legacy link, still valid but deprecated in some environments).
  • UKEurope/London for British time including BST. Not UTC — that is a fixed zero offset that never follows DST.
  • ArmeniaAsia/Yerevan, UTC+04:00, no DST currently observed.

Difference between this tool and the identifier reference

This tool shows the live current offset computed at the moment you load the page. The companion IANA identifier reference lists the standard-time (winter) base offset alongside DST flag for every zone, which is more useful when you need to audit or browse all zones rather than look up one you already have in mind.

Tips and notes

Always store a user’s timezone as the IANA name, not as a numeric offset, because the offset changes with DST and across history. Pass the name to a date library such as the built-in Intl.DateTimeFormat or a library like Luxon to render local times correctly. Keep your runtime’s tz data current, since governments change DST rules and offsets, and stale data produces wrong local times.

The DST column is especially useful in southern-hemisphere deployments where summer falls in January and the DST logic is the opposite of northern-hemisphere intuition.