My Geocode

Guides

Find the time zone for any latitude and longitude

· 3 min read · My Geocode · #timezone#coordinates#lookup

Coordinates alone do not tell you what time it is at a point on the map. The timezone endpoint takes latitude and longitude and returns the time zone name, its current UTC offset, and its abbreviation.

Making the request

GET /v1/timezone?lat=52.3676&lon=4.9041
{
  "status": "ok",
  "timezone": "Europe/Amsterdam",
  "utc_offset": "+02:00",
  "abbreviation": "CEST"
}

The timezone field is a standard identifier you can pass straight into most date and time libraries. The utc_offset and abbreviation fields are useful for display purposes when you want to show a reader something more familiar than an identifier string.

A second example, on the far side of the date line

Offsets are not always small, round numbers, and some places sit on the far side of the date line from most of the world's population.

GET /v1/timezone?lat=-17.7333&lon=168.3273
{
  "status": "ok",
  "timezone": "Pacific/Efate",
  "utc_offset": "+11:00",
  "abbreviation": "VUT"
}

Treat the returned identifier the same way regardless of how far it sits from your own server's clock. Your date library already knows how to handle an eleven hour offset correctly, so there is no special case to write for locations far from your own time zone.

Combining it with geocoding

This endpoint only needs coordinates, so it pairs naturally with forward or reverse geocoding. Geocode an address first to get its latitude and longitude, then pass those straight into /v1/timezone to find out what zone that location sits in, without asking the user anything about time zones directly.

If you already have a visitor's IP address rather than a geocoded address, the /v1/ip endpoint returns a timezone field directly in its own response, without a separate call to this endpoint at all. Reach for /v1/timezone directly when you already have coordinates without an associated IP lookup, such as an address from a customer's shipping profile.

Accounting for daylight saving

The utc_offset and abbreviation reflect the offset in effect for the time you asked about. If you care about a specific date rather than right now, pass a unix timestamp with the time parameter so the response reflects the offset that applied on that date, not today's offset.

GET /v1/timezone?lat=52.3676&lon=4.9041&time=1731000000

A mistake worth avoiding

Calling this endpoint once and caching the utc_offset value long term is a common shortcut that breaks twice a year in places that observe daylight saving. The timezone identifier itself is stable and safe to cache. The offset and abbreviation are not, since they shift with the calendar, so recompute them at display time instead of storing them alongside the identifier.

What it costs

Each timezone lookup is one request. If you are already geocoding an address as part of a signup or checkout flow, adding a timezone lookup for the same location doubles your request count for that flow, from one request to two, which is still trivial against the 2,500 free requests a day included with every key.

Time zone data is easy to get wrong by hand, especially around daylight saving boundaries, so it is worth pulling from a single source rather than maintaining your own offset table. The timezone lookup docs cover the full parameter list.

More in Guides