You are building a scheduling feature. A customer in Kathmandu books a call with a colleague who is in a place where daylight saving time just changed, and your code stores a zone name and does arithmetic from there. The meeting lands an hour off. You trace it back and find the same problem every time: a zone name by itself did not tell you what the clock actually said at that moment.
Geoapify has published a product page that speaks directly to this. Its Timezone API takes a latitude, a longitude and an optional RFC 3339 instant. The opening line is the whole argument: "A time zone name alone is not enough to show the correct local time." So instead of a name, you get a fuller answer back. That means the IANA zone name, whether standard or daylight saving time applies at that moment, the exact UTC offset as both a string and seconds, the abbreviation, the local time, and the next transition with its before and after states. You also get the tzdb_version the answer was computed from.
You can see why that matters for your bug. The geocoding endpoints already return a timezone object, but the post's comparison table is clear about the difference: 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. A second endpoint lists every offset change at a point over a window of up to 366 days, which is what you would reach for if you were scheduling recurring meetings across a year.
There are limits you should know before you wire it in. Instants are supported from 2025-01-01 through 2031-12-31, and a date without a time and offset is rejected with a 400. Every call to either endpoint, including through MCP, costs one credit. The page even ships the JSON-RPC body for the get_timezone tool on the Geoapify MCP server, with an at_unix_seconds argument, so you could hand the lookup to an agent as easily as to your own code.
The post notes there is no marketing figure to discount here, only design decisions, and calls them good ones. Timezones come back as an array because a disputed boundary can carry more than one zone, an edge case most providers hide. The page also documents that "next_transition: null is a normal answer" for places like Phoenix or Kathmandu, where clocks do not move. For you, that saves a support ticket: you will not mistake an empty field for a failure. And publishing the tzdb_version in every response turns a silent data dependency into one you can check.
Now the turn, because the post does not only praise. It looks at what the APIs.io catalog says about the company, and some of that is about the catalog's own record. Geoapify is held across 23 API pages, and three of them are this story. The Timezone API was added on the 2026-11-05 rescore and publishes with the next catalog build. 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 score is 57.8, strong band, with contract governance at 84.5 and discoverability at 80.0, against access clarity at 31.6 and operational transparency at 34.2. A few weeks earlier, on 2026-10-14, the same provider was recorded at 23.5 with governance at 0.0 and 10 API pages. The post's explanation is that 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.
Then comes the part where the catalog files a finding against itself. The remaining gap is on its 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.
What you take away is practical. When your problem is local time at a moment, ask for the moment and not just the zone, and check the tzdb_version when an answer looks wrong. Treat a null next transition as normal. And when you read the low access clarity number, remember that the post itself says part of it reflects how the catalog has mapped the provider, not only what the provider published.
Read the original: https://apis.io/2026/11/06/geoapify-timezone-api-answers-for-an-instant-not-a-zone/