Time Zone by Location

The IANA time zone database

The IANA time zone database— also called the tz database, zoneinfo database, or the Olson database after its original maintainer Arthur David Olson — is the authoritative record of every time zone's historical and current offsets, DST rules, and transitions. It's maintained by IANA (the Internet Assigned Numbers Authority) and updated several times a year. Every major operating system, programming language, and timezone-aware application uses it: Linux, macOS, iOS, Android, Java, .NET, Python, JavaScript's Intl API — all of them ship a copy.

Two design decisions shape how the database works:

• Stable identifiers. Zones are named by region/city — a representative city in the zone, with underscores replacing spaces (America/New_York, not EST). The identifier doesn't change when politics change. Saint Petersburg has been Petrograd and Leningrad in living memory; the tz identifier Europe/Moscow covers that area without ever renaming.
• Historical fidelity.Each zone's rules record what the offset and DST behaviour was at every moment back to the standardisation era of the late 1800s. Convert a date in 1942 in any tz-aware system and you get the right wartime offset for that location — including special cases like Britain's "Double Summer Time".

How the identifier is structured

UTC offset, DST, and what changes when

A UTC offset is the simple part of a time zone: how many hours and minutes ahead or behind UTC the local clock is. Nepal is UTC+05:45. India is UTC+05:30. Newfoundland is UTC-03:30. Most zones are at integer-hour offsets, but a handful sit at half-hour or quarter-hour offsets for historical reasons.

DST (Daylight Saving Time, called Summer Time in the UK) shifts the offset typically by +1 hour during local summer months. The dates and direction depend on the country:

The nearest-city heuristic in detail

This tool returns the IANA identifier for the closest reference city — by great-circle distance — among ~70 well-known cities around the world. It works well when the input is within ~500 km of a reference city and not near an international border. It fails when:

• The input is in a single-zone country with a far anchor. China is one IANA zone (Asia/Shanghai) spanning ~5,200 km west-to-east. A point in Kashgar (west Xinjiang) is closer to Asia/Tashkent in km, but the correct zone is Asia/Shanghai.
• The input is near a border with a different zone. A point in northern Idaho (Mountain Time) may be closer to Vancouver (America/Vancouver, Pacific Time) than to Denver — the heuristic returns the wrong zone.
• The input is in Antarctica.Stations follow their parent country's rules; the heuristic can't infer this.
• The input is over open ocean.Maritime zones aren't in the IANA database; the heuristic returns whichever land zone is nearest, which may differ from the nautical convention.

Ten worked examples — coordinate to IANA zone

The McMurdo and Puerto Rico rows show the heuristic's Achilles heel: when the nearest city by km isn't the correct IANA zone, the result is wrong even when the UTC offset happens to match. For applications where the identifier matters (DST handling, historical conversions, regulatory compliance), use a polygon library.

Misconceptions worth getting straight

"EST and America/New_York are the same thing"

Not exactly. ESTis the abbreviation for "Eastern Standard Time", which is the winter offset of New York (UTC-5). When New York is in DST (March-November) it's on EDT (UTC-4). America/New_York handles the EST/EDT switch automatically; EST alone doesn't. Don't use bare abbreviations in configuration files or APIs.

"The IANA database tells me what time it is in a country"

For most countries yes — single-zone countries have one IANA zone covering the whole nation. But large countries cross multiple zones: the US has 9 zones (incl. Hawaii and Alaska), Russia has 11, Australia has 5. Asking for "US time" is ambiguous; asking for America/New_Yorkisn't.

"DST always shifts by one hour"

Almost always, but not always. Lord Howe Island (Australia) shifts by 30 minutes for DST — the only such case in the IANA database. Some historical periods used other shifts (the UK's World War II "Double Summer Time" was +2 hours in summer + 1 hour in winter, both above GMT).

"Time zones follow longitude / 15 degrees per hour"

Conceptually, yes — Earth rotates 360° in 24 h, so 15° of longitude = 1 hour of time. In practice, political boundaries deform every zone. China spans ~60° of longitude in one zone (officially 4 hours of solar time compressed into one civil hour); India is on UTC+05:30 by historical compromise; some Pacific islands sit on +14 to be on the "same day" as their largest trading partner. Look up the IANA zone, don't calculate from longitude.

"Once I set the time zone, I don't need to think about it again"

The IANA database releases 5–10 times per year as countries change their timekeeping policy. A zone's offset, DST rules, or even existence can change with a single release. For applications that schedule far into the future, keep the tz database (and the Intl runtime that ships with it) up to date.

When to use this tool, when not to

How to verify the result

1. Check the reference-city distance. The report shows how far the nearest reference city is. Under ~200 km in a single-zone country is high confidence; 500+ km or near a border is low.
2. Compare offset to expectation. If the offset looks wrong (e.g. for an obviously US west-coast point, you expect UTC-7 / UTC-8), the heuristic snapped to the wrong reference. Check the input.
3. Escalate for accuracy-critical work. Open a Node REPL with tz-lookup or geo-tz and re-query.

How this tool is built

The reference-city table (~70 cities, in src/lib/coords/timezone-cities.ts) is the entire data dependency. Lookup is a great-circle distance computation over the table — sub-millisecond, runs in the browser. Current local time and offset come from Intl.DateTimeFormat against the matched IANA identifier, also in the browser. The deep report adds nearest-place (Mapbox v6, server-side proxy with no-store) and elevation (USGS 3DEP for US; OpenTopoData SRTM30m elsewhere). Neither coordinate nor zone is logged or retained anywhere.