Testing location data with edge cases, not just happy paths
An address in a well mapped city center tells you almost nothing about how your system handles a rural route, a disputed border, or a query near the poles. Test the hard cases deliberately.
Countries that have changed their time zone rules
It is easy to assume that once you know a country's time zone, you know it for good. In practice, governments change time zone policy more often than most people realize. A country might decide to stop observing daylight saving after using it for decades. Another might shift its standard offset by an hour to align more closely with a major trading partner. A large country might redraw the internal boundary between two of its zones as regional administration changes. None of these are hypothetical categories. Changes like this happen somewhere in the world on a fairly regular basis, even though any one country might go years or decades between changes.
This is precisely the problem the IANA time zone database exists to solve. Rather than storing a single current offset per country, it tracks each named zone as a history of rules over time, with entries added whenever a government announces a change. Software that pulls from a maintained, regularly updated copy of this database picks up changes without any code changes of its own. Software that hardcodes offsets by country, perhaps in a lookup table written once during initial development, will quietly drift wrong the next time any covered country changes its rules, and the failure will not announce itself. It will just start returning incorrect local times for that one country until someone notices.
This is also why storing a UTC offset alone, divorced from a named zone, is risky for any data meant to be used for more than a few months. An offset captured today is a snapshot of a rule that could change. A zone name like Pacific/Auckland or Asia/Kolkata carries a reference to the maintained rule set, so as long as the underlying database is kept current, calculations against that name stay correct even after a rule change, without you needing to touch your own data.
The practical guidance for anyone building on top of time zone data is straightforward. Store zone names, not raw offsets, in your own database. Keep whatever time zone library or data source you depend on updated on a reasonable schedule, since a stale copy behaves exactly like a hardcoded table the moment a covered country changes its rules. And treat a time zone lookup as something to call fresh for calculations tied to real, changing dates, rather than a value to cache indefinitely.
Our time zone lookup returns the current IANA zone name and offset for any coordinate, computed against a maintained rule set rather than a static table, which is the only way to stay correct as countries adjust their own rules over time.