Verifying an address matches its stated postal code before checkout
A mismatched postal code and city on an order form looks like a small typo until it turns into a delivery sent to the wrong part of the country entirely.
Coordinating a remote team across time zones
"UTC minus five" is not a time zone, it is an offset, and offsets change twice a year in most of the countries that observe daylight saving, which is exactly why a twelve-person remote team kept scheduling meetings that landed correctly for months and then suddenly did not, right around a clock change nobody on the scheduling side had thought to check.
The team had been maintaining a simple spreadsheet mapping each teammate's city to a fixed offset from company headquarters, updated by hand whenever someone remembered daylight saving was coming. The spreadsheet was wrong for roughly six months of the year, on a rotating basis, depending on which countries had changed their clocks and which had not, since not every country observes daylight saving on the same schedule, and some do not observe it at all.
The fix was replacing the spreadsheet with a lookup that reflected real time zone rules rather than a snapshot someone had typed in once. For each teammate's city, the team resolved a coordinate and sent it to /v1/timezone, which returns the IANA time zone name for that point, a name like "America/Sao_Paulo" or "Asia/Kolkata" rather than a bare offset. That name carries the actual daylight saving rules for that specific region with it, so a scheduling tool that stores the IANA name and calculates the current offset from it, rather than storing the offset directly, stays correct automatically as clocks change, since the rules live in the time zone database rather than in a value someone has to remember to update.
The team wired this into its meeting scheduling tool directly, so proposing a meeting time showed every attendee's local time correctly, calculated fresh at the moment the meeting was being scheduled rather than pulled from a static table. For a meeting proposed weeks in advance, the endpoint's ability to calculate an offset for a specific future moment mattered too, since a meeting scheduled before one region's clock change and held after it needed the correct post-change offset, not the offset in effect on the day it was scheduled.
The visible change was fewer scheduling mistakes and fewer apologetic messages about a meeting that had landed at an unreasonable hour for someone. The less visible change was that nobody on the team had to remember daylight saving schedules for four countries anymore, which had genuinely been someone's informal, unpaid responsibility before.
This kind of fix scales down as easily as it scales up. A twelve-person team and a thousand-person company have the same underlying problem, just at different volumes, and the lookup itself does not change in complexity either way, only in how often it gets called. For a small team, usage sat trivially inside the free daily allowance included with a key, since resolving a dozen people's time zones a handful of times is a tiny workload next to the 2,500 free requests available each day.
Time zone bugs are usually invisible until they cause a real problem, and by then the damage is a missed meeting or a confused customer. Fixing the underlying data source once removes the whole category of error going forward. Documentation for the endpoint is at /docs/timezone-lookup/.