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.
Time zone data: how the rules actually get maintained
A time zone is a political decision before it is a geographic one. The line between two zones, the decision to observe daylight saving, and the exact date a clock moves forward or back are all set by national or local governments, and any of them can change. This is why time zone data cannot be a static table of offsets frozen at some point in the past. It has to be a maintained record of history, current rules, and known future changes.
The IANA time zone database is the reference most software relies on for exactly this reason. Its maintainers track legal time changes as governments announce them, whether that means a shift in daylight saving policy, a change to which UTC offset a region observes, or a boundary adjustment between zones within a country. Each named zone, like Europe/Amsterdam or America/Chicago, carries not just a current rule but a full history of past rules, because software often needs to compute the correct offset for a date in the past, not just today.
That history matters more than it might seem. A timestamp from several years ago needs the offset that was actually in effect on that date, which may differ from the offset in effect today if the rules changed in between. A time zone lookup that only knows the current rule will silently produce wrong results for historical or future dates, which is why asking a time zone API for the zone at a specific moment, rather than just the zone name, is worth doing whenever the date matters.
This is also why a time zone lookup should return the actual zone name and not just a numeric offset. Europe/Amsterdam carries all of the history and daylight saving logic behind it. +01:00 is only correct for part of the year and tells you nothing about when it changes. Software that stores only the offset for a location will drift out of correctness the next time a daylight saving transition happens, while software that stores the zone name stays correct indefinitely as long as the underlying database is kept current.
My Geocode's time zone lookup returns the IANA zone name and the UTC offset together, and accepts a specific moment in time so the correct offset, including daylight saving, applies for that exact date rather than assuming today's rule always held.