Ein Franchise-Unternehmen mit Standorten in mehreren Zeitzonen hatte ein Website-Problem, an dessen Behebung niemand gedacht hatte: Der zentrale Bereich „Öffnungszeiten“ auf jeder Standortseite zeigte denselben Zeitplan, einmal von jemandem in der Zentrale geschrieben und in jede Filiale kopiert, unabhängig davon, in welcher Zeitzone die jeweilige Filiale tatsächlich arbeitete. Ein Standort im Westen des Franchise-Gebiets, der nach seiner eigenen Uhr um 9 PM schloss, schien auf der Website drei Stunden früher zu schließen, als er es tatsächlich tat, weil die Öffnungszeiten nach der Uhrzeit der Zentrale geschrieben und nie pro Standort angepasst worden waren.
Die Lösung erforderte, jedem Standort eine echte Zeitzone zuzuordnen, statt „Öffnungszeiten“ als einen gemeinsam genutzten Inhalt zu behandeln. Für die Adresse jedes Franchise-Standorts ermittelte das Unternehmen Koordinaten über /v1/forward und übergab diese Koordinaten an /v1/timezone, das den IANA-Zeitzonennamen für genau diesen Punkt zurückgibt. Weil der Name statt eines festen Versatzes gespeichert wurde, blieb die Anzeige der Öffnungszeiten bei Zeitumstellungen automatisch korrekt, ohne dass jemand in der Zentrale daran denken musste, zweimal im Jahr etwas zu aktualisieren.
Mit der eigenen Zeitzone jedes Standorts im System konnte die Website endlich das tun, was sie von Anfang an hätte tun sollen: einem Besucher zeigen, ob ein bestimmter Standort gerade geöffnet ist, korrekt berechnet nach der Uhr dieses Standorts, nicht nach der Uhr des Besuchers und nicht nach der Uhr der Zentrale. Ein Besucher, der vom anderen Ende des Landes aus die Standortseite einer Filiale an der gegenüberliegenden Küste aufrief, sah ein zutreffendes „Jetzt geöffnet“ oder „Geschlossen, öffnet um 8 AM“, das die tatsächliche Ortszeit dieser Filiale widerspiegelte. Das ist die einzige Version dieser Information, die für jemanden, der gleich dorthin fahren will, wirklich nützlich ist.
Speziell für den Standortfinder ergänzte das Unternehmen dies um den Standort des Besuchers selbst. /v1/ip ermittelte die ungefähren Koordinaten eines Kunden, die in dasselbe Entfernungsranking einflossen, das auch andere Finder-Tools verwenden. So erhielt ein Kunde, der nach dem nächstgelegenen geöffneten Standort suchte, Ergebnisse, die sowohl die Entfernung als auch berücksichtigten, ob der jeweilige Standort zum Zeitpunkt der Suche tatsächlich geöffnet war, statt einer nach Entfernung sortierten Liste, in der mehrere gerade geschlossene Filialen zwischen den geöffneten auftauchten.
Das war eine kleine, weitgehend unsichtbare Korrektur, in dem Sinne, dass ein Website-Besucher nie auf die Idee käme, irgendetwas einer „korrekten Zeitzonenbehandlung“ zuzuschreiben. Er würde einfach bemerken, oder wahrscheinlicher nicht bemerken, dass die angezeigten Öffnungszeiten der Realität entsprachen. Das ist im Allgemeinen das Zeichen einer lohnenden Korrektur: Niemand lobt sie, aber alle, die von der alten Version verwirrt worden wären, sind es einfach nicht mehr.
Die Geokodierung lief im Rahmen einer einmaligen Einrichtung einmal pro Standort, ein kleiner Batch angesichts der Zahl der Standorte, die die meisten Franchise-Unternehmen betreiben, und deutlich innerhalb des kostenlosen Tageskontingents. Die Zeitzonenabfragen für die Besucherfunktion „Jetzt geöffnet“ fügten ein leichtes laufendes Volumen hinzu, das an den Traffic des Standortfinders gebunden war und für ein Franchise-Unternehmen mittlerer Größe ebenfalls bequem innerhalb des kostenlosen Kontingents lag, wobei Prepaid-Guthaben bereitstand, falls eine landesweite Marketingkampagne einen ungewöhnlichen Anstieg der Standortsuchen auslöste.
Die Dokumentation zu beiden Endpunkten finden Sie unter /docs/forward-geocoding/ und /docs/timezone-lookup/.