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.
Why time zone bugs are usually a testing problem, not a data problem
A time zone bug almost never shows up on a normal Tuesday. It shows up during the specific week a daylight saving transition happens, or in a region whose government just changed its offset rules with little notice, or at the exact boundary between two zones where an edge case in coordinate-to-zone mapping picks the wrong side. The rest of the year, code that handles time zones badly runs without any visible problem at all, which is exactly what makes these bugs so persistent: the failure mode is rare by design, so it rarely gets caught until it actually happens in production.
We think most of these bugs get blamed on the data when they are really a testing gap. The IANA time zone database, which underlies most serious time zone handling including ours, tracks these transitions and rule changes as they happen. The data being available is not the same as an application correctly exercising the code paths that only run during a transition week or only apply to the handful of regions with unusual rules. If a test suite never simulates a daylight saving boundary, or never runs a lookup against a region with a non-standard half-hour or 45-minute offset, the underlying data being correct will not save an application from a bug that only its own untested code path can prevent.
This is a case where the fix is boring and specific rather than exciting: test explicitly against the calendar dates when transitions occur, not just against an arbitrary date picked because it was convenient. Test against a handful of edge case regions with unusual offsets deliberately, not only against the common, round-number time zones that most development happens to occur in. None of this requires new data. It requires deciding that the rare week is worth testing as carefully as the common one, since the rare week is exactly when the bug will surface for a real user.
There is a related trap worth naming: caching a time zone offset for a location once and reusing that cached value indefinitely. An offset that was correct in July can be wrong in December once daylight saving shifts it, and a cache that does not account for that will confidently serve a stale answer without any indication that anything went wrong. This is not a data quality problem either. It is an architecture decision that assumed a fact would stay constant when the entire nature of the data is that it periodically does not.
We describe our time zone endpoint as one of the parts of the product that is fully working, because the underlying reference data is actively maintained and the lookup logic is built to account for these transitions directly rather than assuming a static offset. The larger point applies beyond our own product: a time zone bug reaching a customer is rarely proof that the source data was wrong. It is much more often proof that nobody wrote a test for the one week a year, or the one region, where the rules actually change.