The trouble with API keys that never expire
A key issued years ago, never rotated, and still valid today is not a convenience. It is a liability nobody has actually looked at in years.
Open time zone data should not be a premium feature
The IANA time zone database is public. It has been maintained openly for decades, tracking every offset change, daylight saving rule, and boundary redraw that governments make. Nearly every serious time zone lookup on the internet, ours included, is built on top of that same public dataset. So when an API charges a separate premium price specifically for time zone lookups, on top of what it already charges for geocoding, it is worth asking what exactly that premium is paying for.
Sometimes the answer is legitimate: engineering time spent keeping the mapping between coordinates and time zone boundaries accurate as those boundaries shift, and infrastructure to serve lookups at scale. That is real work and it costs something. What is less legitimate is treating time zone data as a separate product line with its own pricing tier, priced well above the marginal cost of a lookup, because it can be bundled into a workflow a customer already needs and is less likely to shop around for separately.
We do not split time zone out as a premium add-on. It is one endpoint among several, priced the same as every other endpoint: covered by the free daily allowance, and beyond that billed at the same €0.0001 per request as everything else, or included under the same €50 Unlimited key. There is no separate time zone tier and no markup for asking what time it is at a set of coordinates.
Time zone lookups matter more than their unglamorous name suggests. Scheduling systems, logging pipelines, booking platforms, and anything that needs to show a user the correct local time all depend on getting this right. Get it wrong and a meeting invite lands an hour off, a log timestamp misleads an investigation, or a delivery window promises the wrong local hour. This is exactly the kind of lookup that should be cheap and boring, not a line item that shows up as a surprising jump on an invoice.
Part of the reason time zone lookups get treated as a premium feature elsewhere is that daylight saving transitions and boundary changes make the underlying data look more complicated than static country codes. It is genuinely fiddly data to maintain. But fiddly to maintain is not the same as expensive to serve per request, and pricing should track the latter, not the complexity of the former.
Charging a premium for time zone data also creates a bad incentive at the API design level: providers stop wanting to expose it directly and start wanting to wrap it into bigger, more expensive bundles instead, on the theory that a feature nobody can price check individually is easier to mark up. We think the opposite approach earns more trust. Make the endpoint plain, price it the same as anything else, and let developers use it exactly as often as their application needs, without doing mental math about whether this particular lookup is the expensive kind.