Timezones normalize
Exacttimezones_normalizeDeterministic and authoritative — the canonical answer for this input.
Normalize a timezone reference (IANA name, abbreviation like EST/ET, friendly label like 'Eastern Time' or 'Tokyo', or offset like GMT-5) to its canonical IANA name with current UTC offset and DST flag. An ambiguous abbreviation with no resolving country_hint returns a default pick with is_ambiguous=true at confidence 0.5 (the pick is a guess — 'EST' could be US Eastern or Australian Eastern); a hint that resolves it restores 1.0. Use timezones_abbreviation_resolve for strict handling. Processing multiple inputs? Use `timezones_normalize_batch` to do up to 1000 in one call.
Parameters
valuestringrequiredcountry_hintstringoptionalOptional country (ISO2, ISO3, or name — e.g. 'IE', 'Ireland') to disambiguate ambiguous abbreviations; matched against each candidate zone's country.
Call it
curl -X POST https://api.snipget.ai/v1/timezones/normalize \
-H "Authorization: Bearer sk_live_..." \
-H "Content-Type: application/json" \
-d '{"value":"Eastern Time"}'The Batch tab sends up to 1000 inputs in one call via /v1/timezones/normalize/batch.
FAQ
Why use this instead of letting my AI write the timezone string?
Models routinely invent or mangle timezone identifiers, mixing up abbreviations, city names, and IANA names. This maps any of those to the one canonical IANA name (like America/New_York) using a maintained abbreviation table, and adds the current UTC offset so you do not have to track daylight saving yourself.
What does it NOT do?
It does not convert a clock time from one zone to another. It identifies and standardizes the zone only. When an abbreviation is ambiguous (CST can mean US Central or China Standard), it picks a sensible default, sets is_ambiguous to true, and drops confidence to 0.5 because the pick is a guess — pass a country_hint to resolve it and restore full confidence, or use the abbreviation-resolve tool when you want it to stop and ask instead.
What forms can I pass in?
IANA names (America/New_York), abbreviations (EST, CST, JST), friendly labels (Eastern Time, Tokyo, London), and plain offsets (GMT-5, +05:30). An offset with no matching named zone comes back with the offset filled in but iana set to null.
Is the answer reliable?
The IANA mapping is exact, meaning deterministic and authoritative, so the same input always resolves to the same zone. The offset and is_dst_now fields reflect the moment you call it, since daylight saving shifts the live offset.
What happens if I send something it cannot read?
Gibberish or an unrecognized string returns confidence 0 with a why_invalid note explaining the problem. It does not throw an error, so you can read the reason and move on.