„UTC minus fünf“ ist keine Zeitzone, sondern eine Zeitverschiebung, und Zeitverschiebungen ändern sich in den meisten Ländern mit Sommerzeit zweimal im Jahr. Genau deshalb plante ein zwölfköpfiges Remote-Team monatelang Meetings, die richtig lagen, und dann plötzlich nicht mehr, genau um eine Zeitumstellung herum, an die bei der Planung niemand gedacht hatte.
Das Team pflegte eine einfache Tabelle, die der Stadt jedes Teammitglieds eine feste Zeitverschiebung zur Unternehmenszentrale zuordnete und von Hand aktualisiert wurde, wenn jemand daran dachte, dass die Sommerzeit bevorstand. Die Tabelle war etwa sechs Monate im Jahr falsch, und zwar wechselnd, je nachdem, welche Länder ihre Uhren umgestellt hatten und welche nicht, denn nicht jedes Land stellt nach demselben Zeitplan auf Sommerzeit um, und manche kennen gar keine.
Die Lösung bestand darin, die Tabelle durch eine Abfrage zu ersetzen, die echte Zeitzonenregeln abbildet statt einer Momentaufnahme, die jemand einmal eingetippt hatte. Für die Stadt jedes Teammitglieds ermittelte das Team eine Koordinate und sendete sie an /v1/timezone, das den IANA-Zeitzonennamen für diesen Punkt zurückgibt, also einen Namen wie „America/Sao_Paulo“ oder „Asia/Kolkata“ statt einer bloßen Zeitverschiebung. Dieser Name trägt die tatsächlichen Sommerzeitregeln für genau diese Region in sich. Ein Planungstool, das den IANA-Namen speichert und daraus die aktuelle Zeitverschiebung berechnet, statt die Zeitverschiebung direkt zu speichern, bleibt deshalb bei Zeitumstellungen automatisch korrekt, denn die Regeln stehen in der Zeitzonendatenbank und nicht in einem Wert, an dessen Aktualisierung jemand denken muss.
Das Team band dies direkt in sein Tool zur Meetingplanung ein, sodass bei einem Terminvorschlag die Ortszeit jedes Teilnehmers korrekt angezeigt wurde, frisch berechnet im Moment der Planung statt aus einer statischen Tabelle gezogen. Bei Meetings, die Wochen im Voraus vorgeschlagen wurden, kam es auch darauf an, dass der Endpunkt eine Zeitverschiebung für einen bestimmten zukünftigen Zeitpunkt berechnen kann, denn ein Meeting, das vor der Zeitumstellung einer Region geplant und danach abgehalten wurde, brauchte die korrekte Zeitverschiebung nach der Umstellung und nicht die am Tag der Planung gültige.
Die sichtbare Veränderung waren weniger Planungsfehler und weniger entschuldigende Nachrichten wegen eines Meetings, das für jemanden zu einer unzumutbaren Uhrzeit lag. Die weniger sichtbare Veränderung war, dass sich niemand im Team mehr die Sommerzeitregeln von vier Ländern merken musste, was zuvor tatsächlich die inoffizielle, unbezahlte Aufgabe einer bestimmten Person gewesen war.
Diese Art von Lösung lässt sich genauso leicht verkleinern wie vergrößern. Ein zwölfköpfiges Team und ein Unternehmen mit tausend Mitarbeitern haben dasselbe grundlegende Problem, nur in unterschiedlichem Umfang, und die Abfrage selbst wird in keinem Fall komplexer, nur häufiger aufgerufen. Für ein kleines Team lag die Nutzung mühelos innerhalb des kostenlosen Tageskontingents, das zu einem Schlüssel gehört, denn die Zeitzonen von einem Dutzend Personen ein paar Mal zu ermitteln, ist eine winzige Last im Vergleich zu den 2.500 kostenlosen Anfragen, die jeden Tag zur Verfügung stehen.
Zeitzonenfehler bleiben meist unsichtbar, bis sie ein echtes Problem verursachen, und dann ist der Schaden ein verpasstes Meeting oder ein verwirrter Kunde. Wenn Sie die zugrunde liegende Datenquelle einmal korrigieren, beseitigen Sie diese ganze Fehlerkategorie für die Zukunft. Die Dokumentation zum Endpunkt finden Sie unter /docs/timezone-lookup/.