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.
Half-hour and 45-minute time zones, explained
Most developers write their first time zone handling code assuming every offset is a whole number of hours from UTC. That assumption holds for a majority of zones, and then breaks the first time a request comes in from somewhere that does not follow it. Several parts of the world use offsets on the half hour, and at least one region uses a 45 minute offset, and none of these are edge cases in the sense of being rare or invalid. They are simply how those places have chosen to set their clocks relative to the sun and to their neighbors.
A half hour offset usually reflects a country's longitude sitting between two standard hourly zones, with a decision to split the difference rather than round to one side. A 45 minute offset is rarer still and tends to reflect a similar in-between position combined with a deliberate choice to stay distinct from a neighboring standard offset. Neither is a mistake in the data. Both are legitimate legal time zones tracked the same way as any hourly zone in the IANA database.
Where this actually breaks software is in date and time math that hardcodes assumptions. Code that rounds offsets to the nearest hour, that stores an offset as an integer number of hours, or that builds a dropdown list of time zones using only whole and half hour increments will silently mishandle these zones. The failure is usually quiet too. Times will be off by fifteen or thirty minutes rather than throwing an obvious error, which makes the bug easy to miss in testing and only show up when a real user in the affected region reports something wrong.
The fix is straightforward if you build for it from the start: always work with the actual UTC offset returned for a zone, expressed with minute precision, rather than assuming or rounding to hours. Store and compare zone names rather than offsets where possible, since the name carries the exact current and historical offset without you needing to hardcode anything.
A time zone lookup that returns the precise offset alongside the IANA zone name removes the guesswork here. Query the coordinates or the zone directly rather than assuming a location's offset from its country or region alone, since offsets can vary within a single country and rarely align neatly to the hour everywhere.