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.
Daylight saving transitions and the requests that break around them
Twice a year, in zones that observe daylight saving, something odd happens to the clock that most software never accounts for. When clocks move forward, an hour of local time simply does not exist, so a timestamp like "2:30 AM" on that date never actually occurred. When clocks move back, an hour happens twice, so "1:30 AM" occurred once before the change and once after, and a bare local timestamp with no other information cannot tell you which one is meant.
This is not a rare edge case that only matters for exotic use cases. It is a routine calendar event that recurs every year in every zone that uses daylight saving, and it silently breaks any code that treats local time as always well defined. A scheduling system that stores "book this for 1:45 AM" without also storing the UTC offset at the moment of booking cannot know, months later, which of the two 1:45 AMs was intended if the booking falls on transition night.
The safest practice is to store timestamps in UTC everywhere internally and only convert to local time for display. UTC has no daylight saving and no ambiguity, so once a moment is captured that way, it stays correct regardless of what happens to local clock rules later. Convert to the user's local time zone only at the point of showing it to them, using the current rules for that zone at that specific moment, which is exactly why a time zone lookup that accepts a specific point in time, not just a location, is worth using rather than caching an offset once and reusing it.
Edge cases worth testing explicitly if you build anything that schedules or logs events include: a booking made for the nonexistent hour during a spring-forward transition, a timestamp during the repeated hour of a fall-back transition, and a scheduled event whose date crosses a transition between when it was created and when it occurs. None of these are hypothetical. They happen on a fixed, predictable schedule every year, and testing them once during development is far cheaper than debugging a support ticket about a meeting that appeared to move by an hour.
If your system needs the correct offset for a specific moment rather than just the zone name, request it directly rather than deriving it from a cached value. My Geocode's time zone lookup accepts a specific moment and applies daylight saving rules for that exact date, so the offset returned is correct even right at the edge of a transition.