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.
The International Date Line and the requests that cross it
Stand a short distance from the International Date Line and it is entirely possible for your neighbor across that line to be experiencing a different calendar date than you are, even though you are both looking at roughly the same local clock time and are physically close to each other. This is one of the more genuinely disorienting facts about how the world's timekeeping is organized, and it has real, practical consequences for any date-sensitive logic operating near it.
The date line exists because time zones accumulate around the globe until they meet somewhere, and by long-standing convention that meeting point runs roughly along the 180th meridian in the Pacific, deliberately routed through open ocean and around inhabited land as much as practical specifically to minimize how many places sit right on top of the jump. Crossing it in one direction moves your calendar date back a day. Crossing it in the other moves it forward a day. This is separate from and additional to the ordinary time zone offset difference you would expect from crossing any other zone boundary.
For most applications this simply never comes up, since the date line runs mostly through ocean and the number of people and businesses operating right at its edge is small. It becomes a real concern specifically for applications operating in the Pacific island nations and territories near the line, where a scheduling system, a booking platform, or anything computing "which day is it right now at this location" needs to get the date line's exact routing right, not just the general time zone offset, or it will compute a plausible-looking but wrong calendar date for locations very close to it.
This is exactly why relying on a proper time zone lookup, tied to the actual IANA zone for a specific location, matters more here than almost anywhere else. A naive calculation based purely on longitude and a simple offset formula will get the date line wrong, since the line's actual path deliberately deviates from a straight line of longitude in several places specifically to keep some island nations and territories on a single consistent date rather than splitting them awkwardly across the line.
If your application operates anywhere near the Pacific and computes dates, not just times, based on location, use a proper time zone lookup tied to the actual zone for that coordinate rather than deriving the date from longitude directly, and test explicitly against locations known to sit close to the date line rather than assuming your general time zone handling automatically covers this specific edge case correctly.