From coordinates to correct local time: timezone handling that never breaks

Timezones are where correct code goes wrong: hard-coded offsets, forgotten daylight-saving jumps, a server in UTC guessing what 'tomorrow 9am' means for a user in Auckland. Resolve the zone from location once, store UTC, and the whole class of bugs disappears.

Get the zone from a location

Given coordinates — from a GPS fix or an IP lookup — the Timezone endpoint returns the IANA zone id, the current UTC offset, and whether daylight saving is active right now.

curl "https://api.locabium.com/v1/timezone?lat=-36.848&lon=174.763" \
  -H "Authorization: Bearer $LOCABIUM_KEY"

{
  "timezone": "Pacific/Auckland",
  "utc_offset": "+13:00",
  "dst": true,
  "abbreviation": "NZDT",
  "local_time": "2026-07-05T22:41:00+13:00"
}

No coordinates? Start from the IP

On the web you usually don't have GPS. Resolve coordinates from the visitor's IP first, then feed them to the Timezone endpoint — or pass the IP directly.

curl "https://api.locabium.com/v1/timezone?ip=203.86.207.1" \
  -H "Authorization: Bearer $LOCABIUM_KEY"

The one rule that fixes timezone bugs

1. Store every instant in UTC. Always.
2. Store the user's IANA zone id (e.g. Pacific/Auckland) — never a raw offset, which changes twice a year.
3. Convert to local time only at the moment you render, using the stored zone.

A UTC offset is a snapshot, not a timezone. `+13:00` is Auckland in summer and `+12:00` in winter — store `Pacific/Auckland` and let the zone database handle the jump.