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.
Leap seconds, UTC, and why they rarely matter to you
The Earth's rotation is not perfectly constant, and Coordinated Universal Time, the basis for virtually all civil timekeeping, is defined against a very precise atomic standard rather than the planet's actual, slightly irregular spin. To keep UTC from drifting away from the Earth's real rotation over time, an extra second, a leap second, is occasionally inserted, which is why UTC and the strict atomic time standard it is built on very gradually diverge and then get periodically corrected back into alignment.
For almost every application that touches time zones or timestamps, this is a piece of trivia rather than a practical concern. A leap second is an exceedingly rare, deliberately scheduled event, and the vast majority of software, including virtually anything built on top of a standard operating system clock, handles it transparently at the system level long before your application code ever sees a timestamp. You are extremely unlikely to write code that behaves differently because of a leap second unless you are working in a domain that specifically requires sub-second precision timing over long spans, such as certain scientific, financial, or satellite navigation systems, which is a genuinely narrow slice of software overall.
Where leap seconds occasionally do surface as a real, if usually minor, engineering concern is in systems performing very precise duration calculations across a leap second boundary, where naive time arithmetic can be off by exactly one second if it does not account for the adjustment. Most general-purpose applications, anything computing a duration in whole seconds or larger units for ordinary business purposes, will never notice, since a single second of drift is well within the tolerance of essentially every everyday use case.
It is worth mentioning here mainly because it rounds out the full picture of how civil time actually works, alongside the more practically significant subjects of daylight saving transitions and time zone rule changes covered elsewhere. Leap seconds are a real and interesting quirk of how UTC is maintained, but they are not something you need to build defensive logic around for the overwhelming majority of applications, including virtually anything built around location, scheduling, or timestamp handling using our time zone lookup. If your specific domain does require sub-second timing precision over long durations, that is a specialized concern worth handling explicitly and separately, well outside the scope of typical location-aware software.