Geoapify has published a product page that reads like a specification. The Timezone API takes a latitude, a longitude and an optional RFC 3339 instant, and returns the IANA zone name, whether standard or daylight saving time applies at that moment, the exact UTC offset in both string and seconds, the abbreviation, the local time, the next transition with its before and after states, and the tzdb_version the answer was computed from. The opening line is the whole argument: “A time zone name alone is not enough to show the correct local time.” A second endpoint lists every offset change at a point over a window of up to 366 days, and every call to either, including through MCP, costs one credit. Instants are supported from 2025-01-01 through 2031-12-31, and a date without a time and offset is rejected with a 400.
There is no marketing figure to discount, only design decisions, and they are good ones. Returning timezones as an array because a disputed boundary can carry more than one zone is the kind of edge most providers hide. Documenting that “next_transition: null is a normal answer” for Phoenix or Kathmandu, where clocks do not move, saves a support ticket. Publishing the tzdb_version in every response turns a silent data dependency into a checkable one. The comparison table against the timezone object the geocoding endpoints already return is also clear: that object gives a zone and both offsets in general, while this endpoint gives the one offset that applies at the instant you asked about. The page even ships the JSON-RPC body for the get_timezone tool on the Geoapify MCP server, with an at_unix_seconds argument.
The catalog holds Geoapify across 23 API pages in the record, and three of them are this story. The Geoapify Timezone API is the endpoint pair described here, added to the record on the 2026-11-05 rescore and publishing with the next catalog build, and the page positions it against the timezone object in the Geoapify Geocode API and the Geoapify Reverse Geocoding API. The record corroborates the page: 23 provider-published OpenAPI 3.1 documents, an API key in the query or an x-api-key header, an EU-only mirror at api-eu.geoapify.com, a remote MCP server with 12 tools, and a free tier of 3,000 credits a day. The MCP server, well-known catalog, agent skills, error semantics and OpenAPI examples dimensions are all lit.
The Kin Score is 57.8, strong band, rescored on 2026-11-05, with contract governance at 84.5 and discoverability at 80.0 against access clarity at 31.6 and operational transparency at 34.2. On 2026-10-14 this blog recorded the same provider at 23.5 with governance at 0.0 and 10 API pages, so the index Geoapify asked tools to read has now been read. The Agent Readiness score is 46.5, agent-ready, with idempotency and pagination ratio unlit, neither of which a single-point lookup needs. The remaining gap is on our side: the agentic access profile maps one operation against 23 APIs and a 12-tool MCP server, and a page that documents its own 400, 401 and 429 responses deserves an access clarity facet that says so.