Time Zone Names, Your Way: Case-Insensitive IANA Zones and UTC Aliases

Time zone names arrive from everywhere: user profiles, CSV exports, config files, a dropdown somebody built in 2014. They don't always arrive in the exact case tzdata uses. Until now that meant normalising them yourself before calling the API.

Not anymore. The tz selector now matches IANA zone names case-insensitively, and accepts UTC, GMT and every Etc/* zone.

Any case works

curl "https://api.timelogicapi.com/v1/time/convert?unix=1782000000&tz=america/new_york" \
  -H "Authorization: Bearer $TIMELOGIC_API_KEY"

{
  "unix": 1782000000,
  "unix_ms": 1782000000000,
  "utc": "2026-06-21T00:00:00Z",
  "iso_local": "2026-06-20T20:00:00-04:00",
  "rfc2822": "Sat, 20 Jun 2026 20:00:00 -0400",
  "human": "June 20, 2026, 8:00 PM America/New_York",
  "day_number": 7,
  "day_short": "Sat",
  "day_full": "Saturday",
  "timezone": "America/New_York"
}

america/new_york, AMERICA/NEW_YORK and America/New_York give the same answer.

You get the canonical name back

The response's timezone field is always the canonical IANA name, whatever you sent. Store that value and your data stays consistent:

The last row is tzdata at work: Europe/Stockholm is a link to Europe/Berlin, so both give identical local times.

UTC, GMT and fixed-offset zones

UTC and GMT work as zone names, and so do the fixed-offset Etc/GMT±N zones. One thing that catches everyone: the sign in Etc/GMT names is inverted, a POSIX convention. Etc/GMT-14 is fourteen hours ahead of UTC:

curl "https://api.timelogicapi.com/v1/time/convert?unix=1782000000&tz=Etc/GMT-14" \
  -H "Authorization: Bearer $TIMELOGIC_API_KEY"

returns "iso_local": "2026-06-21T14:00:00+14:00". If you mean "UTC plus a fixed amount", the offset selector reads more naturally (see Selectors).

Unknown names stay loud

Case-insensitive doesn't mean anything goes. A name that isn't in tzdata returns a 400 that echoes what you sent:

{
  "error": {
    "code": "INVALID_PARAMETER",
    "message": "Invalid timezone.",
    "details": { "tz": "Mars/Olympus" }
  },
  "request_id": "7b118d04-2dba-413d-bd5d-2d855d01b9bb"
}

Why it matters

One less normalisation step between your users' data and a correct timestamp. Pass the zone name you have, store the one you get back.

Full selector rules are in the docs; try it in the API reference.