My Geocode

Guides

Build a time zone picker that defaults to the visitor's zone

· 3 min read · My Geocode · #timezone#ip-lookup#forms#ux

Scrolling through a list of time zone names to find your own is a small annoyance that a sensible default removes for almost everyone.

Detecting the zone

The /v1/ip endpoint returns a timezone field directly, so a single call gives you both the location and the time zone identifier together, without a separate call to the timezone endpoint.

GET /v1/ip?ip=203.0.113.88
{
  "status": "ok",
  "ip": "203.0.113.88",
  "version": 4,
  "found": true,
  "country": "Australia",
  "country_code": "AU",
  "region": "New South Wales",
  "city": "Sydney",
  "postcode": "2000",
  "lat": -33.8688,
  "lon": 151.2093,
  "timezone": "Australia/Sydney",
  "asn": 7890,
  "org": "Example Networks"
}

Pre-selecting the picker

Set the timezone value from this response as the selected option in your settings form when it first renders, server-side, before the page reaches the visitor. This works the same whether the picker is a dropdown of standard zone identifiers or a searchable list, since the value you are pre-selecting is just a standard identifier string like the one in the example.

A second example: multiple people on one booking

A travel or event booking form that collects details for more than one traveler benefits from detecting a zone once for the person filling out the form, then applying it as the shared default for every traveler entry rather than looking it up again per traveler. Each traveler field stays editable individually, since a group booking often includes people joining from a different zone than whoever is filling in the form.

Letting the visitor override it

A time zone picker exists specifically because IP-based detection is not always right, particularly for a visitor on a VPN or traveling. Always leave the field editable and save whatever the visitor explicitly picks over the detected default, without re-detecting and overwriting their choice on a later visit.

A common mistake to avoid

Do not assume a large country maps to a single time zone just because your example lookups happen to show one clean identifier. Countries spanning multiple zones will return whichever specific zone matches the visitor's actual location, which is exactly the detail that makes IP-based detection more useful than a country-level guess, but only if your form trusts the specific identifier returned rather than substituting a single default zone for the whole country.

Detect once, not every visit

Run the detection once, the first time a visitor sets up their account or preferences, and store the result. Re-running it on every login would waste requests without adding value, since a visitor's chosen zone, once set deliberately, should stick unless they change it themselves.

If you already have specific coordinates rather than an IP address, such as a delivery address a visitor typed in, /v1/timezone resolves the zone directly from latitude and longitude and can also accept a specific timestamp, which is useful when you need to know the zone as it applied at a particular moment rather than right now.

What it costs

A single lookup per new account or preferences setup is one request. Even a service signing up a steady stream of new users each day stays well inside the 2,500 free requests a day included with every key or available from a single address without one, using this feature alone.

Detecting a sensible default and then getting out of the way is the right balance for a time zone picker. Full field details are on the IPv4 lookup docs and the timezone lookup docs.

More in Guides