Time Zones by Name, and a Home for WorldTimeAPI's Clients

A clock is the kind of call that gets written once and then left to run: in an agent that stamps its records, a game server, a board on a wall. Nobody changes code like that every season, which is the problem with a fixed offset.

A fixed offset is wrong for half the year

/datetime/+0200 is Oslo in summer. From 01:00 UTC on 25 October 2026, when Europe goes back to standard time, it is Oslo plus an hour, and it stays wrong until someone edits the offset. A zone name does not have that problem, because the zone carries its own rules:

GET /services/v1/datetime/Europe/Oslo
{"datetime":"2026-10-03T12:11:28+02:00","timezone":"Europe/Oslo","abbreviation":"CEST","utc_offset":"+02:00","dst":true,"unixtime":1791022288,"raw_offset":3600,"dst_offset":3600,"dst_from":"2026-03-29T01:00:00+00:00","dst_until":"2026-10-25T01:00:00+00:00","day_of_week":6,"day_of_year":276,"week_number":40,"utc_datetime":"2026-10-03T10:11:28+00:00"}

Any IANA name works, in any case, including three-part names such as America/Argentina/Buenos_Aires. The answer by name says what the offset is right now, whether summer time is on and when it began and ends, since that is the reason to ask by name, and the day and week numbers with it. An unknown name is a 400 with a fix rather than a quiet UTC, because a wrong hour that looks right is the exact failure this is meant to remove.

The offset forms are unchanged. Clients that expect {"datetime": ...} and nothing else keep getting exactly that. +02:00 with a colon is now accepted beside +0200, and an hour-only value such as /datetime/1 is still not a route.

WorldTimeAPI's fields, under our paths

WorldTimeAPI was the clock in a great many ESP32 sketches, Arduino projects, games and scripts. On 3 October 2026 it did not answer us: every connection we made to worldtimeapi.org was reset, over HTTP and HTTPS, and from a second network as well. Its fields answer here, under the paths the rest of this API uses:

The field names and types are WorldTimeAPI's: the local and UTC time, the offset in force, the standard offset, whether summer time is on and when the current period began and ends, the day of the week and of the year, the ISO week and the Unix time. Three things differ. There is no client_ip; /ip_datetime answers ip, the address it looked up. The times end at the second, without microseconds. And every answer is JSON, with no .txt form. /ip_datetime finds the zone of an address with an address lookup. Each worker caches the result by IP and reuses it for up to an hour. That is a refresh interval, not a deletion deadline. IP addresses in request paths can also appear in access logs.

For a few hours on 3 October the same fields also answered under /services/v1/worldtime, in WorldTimeAPI's own path layout. We took that down the same day. One path for each answer, in the structure every other endpoint follows, is easier to keep right than two.

Checked before writing

From a laptop in Norway, against the live service.

The answers took 125 to 236 ms there and back, over a fresh TLS connection every time, which is almost all of it network. Not every public address has a zone: 1.1.1.1 answered 404 rather than a guess, and asking by zone name is the way around that.

Where it sits

The datetime page, the IP datetime page and the time guide have the details, the WorldTimeAPI alternative page has the translation, the fields and the ESP32 change, and the Python and JavaScript clients and the OpenAI tool definitions in the public repository have the new calls. The free MCP server's get_current_time already took a zone name and is unchanged. Every path counts towards the 5000 calls per address per day like the rest of the API.