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.
What "real-time" location data actually requires
"Real-time" gets attached to a lot of location data products as shorthand for fast response times, and speed is a real and worthwhile thing to optimize for. It is also a different claim entirely from what "real time" should actually mean for data that describes something about the current state of the world: that the answer reflects what is true right now, not a fast, low-latency lookup against a dataset that itself was compiled some time ago and has not been meaningfully updated since.
This distinction matters most for IP geolocation specifically, because the mapping between IP address ranges and their physical location changes over time as address blocks get reassigned, reallocated, or repurposed by the regional internet registries that manage them. A lookup that responds in a few milliseconds against a stale mapping is fast and wrong at the same time, and speed does nothing to fix the wrongness. Genuine real time IP geolocation requires the underlying mapping itself to be kept current, with a live lookup process and a cache that gets refreshed rather than treated as a fixed, one-time snapshot.
We built our IP geolocation specifically around this distinction: it runs live, with caching used to keep response times low, not as a substitute for freshness, and a background retry process that keeps working through data that needs rechecking rather than a periodic cron job standing in as the only mechanism for keeping the mapping current. The goal is that the cache makes it fast without making it stale, which is a different design goal than a cache that exists purely to avoid ever recomputing anything, current or not.
The same distinction applies, in a different form, to time zone data. A fast response describing an offset that has not accounted for a recent daylight saving transition or a recent government rule change is not real time in any meaningful sense, even if it returned in ten milliseconds. Real time here means the underlying reference, the IANA time zone database in this case, is being tracked and applied as it changes, not that the response arrived quickly against a table nobody has touched recently.
We think "real time" deserves to be treated as a claim about data currency first and response latency second, even though latency is the part that is easiest to measure and demonstrate. A provider can genuinely optimize response time to a fraction of a second while quietly letting the underlying data go stale for months, and from the outside, a fast wrong answer and a fast right answer look identical until something downstream depends on the difference. The harder, less visible work is keeping the data itself current. That is the part that actually earns the label, and it is also the part a customer cannot verify just by timing a request.