Timezone Lookup

Resolve a coordinate to its IANA timezone, with the offset, whether summer time is in force and the next clock change.

Overview

A timezone is not a slice of the globe. It is a region that has agreed on a clock and on when to change it, and its boundaries follow borders and coastlines, which is why a timezone map looks nothing like neat stripes.

Give this a point and it answers with the region's identifier in the tz database, the list every operating system uses, along with what the clock there reads now and when it next moves.

Web interface

One field, and Enter. The dice fills it with a random example. There is no map on the page, deliberately; see Privacy.

The clock in the answer is the one the server read when it answered. It is not ticked forward in the browser, because a counter would drift against the offset it was computed with, and the question is what the clock says there rather than what it says to the second.

What the field accepts

Every notation the Coordinate Formats tool takes, because it is literally the same parser. A second one that understood fewer forms would only be a way to disagree with the first.

A Plus Code written with a space instead of its plus sign is also read. In a query string a plus means a space by definition, so ?q=9F2C2HG5+M8Q arrives as 9F2C2HG5 M8Q, and refusing someone's own code over that would be unhelpful.

The identifier, not the offset

The answer leads with the identifier, Europe/Berlin rather than +02:00, and that ordering is the point. An offset is true for part of the year; an identifier is true for as long as the region exists, and it is what a database column, a cron expression or a calendar entry should hold.

Storing an offset instead is the mistake behind most timezone bugs: the value is right when it is written and wrong six months later.

The abbreviation is given where one exists. CEST and MST are real because they are used locally, but much of the world has none, so the tz database writes +0545 for Nepal. That is the correct answer rather than a gap.

Summer time and transitions

Roughly a third of the world moves its clocks twice a year, a third never has, and a few have stopped recently: Brazil abolished it in 2019, and Arizona never adopted it while the rest of the United States did.

So three answers are all normal, and the third is not a missing one:

A transition is given in the local clock, which is how a change is announced: at 03:00 the clocks go back to 02:00. The countdown is in whole days, because that is how anyone asking about a clock change thinks about it.

The standard offset is read from the transition list rather than from January. The southern hemisphere has summer time in January, and the Gulf has none at all, so January is not a reliable place to look.

Points at sea

Open water is covered, so every coordinate on earth has an answer. The zones there are named Etc/GMT+2 and the like, 25 of them from +12 to -12.

Those names carry the POSIX sign, which is inverted. Etc/GMT+2 means UTC minus two hours, and Etc/GMT-5 means UTC plus five. This is not a quirk of this tool; it is how the tz database has always spelled them, and it catches people out constantly. The answer says so whenever such a zone comes up, because otherwise one of the two numbers looks like a mistake.

Where two zones overlap

The zones in this data are not everywhere disjoint. Where two overlap it is because the territory is claimed by more than one administration, not because the file is broken, and which clock applies there is not a question a converter can settle.

Measured on the 2026d boundaries, the overlaps are between Asia/Shanghai and Asia/Urumqi, which is by far the largest, then Africa/Juba and Africa/Khartoum, Asia/Tbilisi and Europe/Moscow, Asia/Hebron and Asia/Jerusalem, America/Argentina/Rio_Gallegos and America/Punta_Arenas, and Asia/Kathmandu and Asia/Kolkata, among a handful of smaller ones.

The answer leads with the smaller polygon, as the more specific claim, and then names the others in also_claimed_by with a sentence saying what has happened. Choosing one silently would present a political question as a technical result.

Two sources, kept apart

The answer is assembled from two things that have nothing to do with each other, and knowing which is which matters when one of them is out of date.

Neither is a call to anyone at run time. The answer names the tz database version it used, because the two copies are released separately and can be a version apart: a rule that changed in the last few weeks may be in the boundary build before it is in the rules.

The boundaries use the full variant rather than the merged one. The merged build collapses every zone whose rules currently agree, which turns 444 zones into 65 and loses Europe/Berlin, Europe/Oslo, Europe/Vienna, Europe/Zurich and America/Toronto. Answering Frankfurt with another city's identifier would be technically equivalent and useless.

URL parameters

API

https://api.troubleshooting.tools/v1/lookup/timezone/{coordinate}.

There is no rate limit. A lookup is one point in polygon test against a local table.

Errors

Privacy

Both halves of the answer are on this server, so the coordinate is never forwarded to a timezone service or anyone else.

There is no map on the page for that reason. A map would make your browser fetch tiles from whoever serves them, and the coordinate would travel with the request for them.