Ein Support-Mitarbeiter in einem Büro, der ein Ticket sieht, das um „3:47 AM“ eingereicht wurde, hat keine Ahnung, ob das für den Kunden spät oder mitten im Arbeitstag ist. Zeitstempel ohne Zeitzone sind nahezu nutzlos, wenn sich die Kunden eines Unternehmens über mehrere Kontinente verteilen, und ein Softwareunternehmen mit Support-Teams in drei Regionen stieß ständig auf dieses Problem. Die Mitarbeiter öffneten Tickets, prüften das Rechnungsland des Kunden und schlugen dann von Hand nach, ob dieses Land vor- oder nachging, und lagen oft genug falsch, dass „Entschuldigen Sie die frühe Störung“ im Büro zum Running Gag wurde.
Das Unternehmen ersetzte das Rätselraten durch zwei Aufrufe beim Eingang eines Tickets. Zuerst liest /v1/ip die IP-Adresse des Besuchers und gibt Land, Region, Stadt und Koordinaten zurück, dazu direkt in derselben Antwort ein Zeitzonenfeld. Für die meisten Tickets reichte dieses Feld allein aus. Für die kleinere Zahl von Fällen, in denen mehr Genauigkeit zählte, etwa bei der Planung eines Rückrufs, wurden die Koordinaten aus dieser Abfrage an /v1/timezone übergeben, das den IANA-Zeitzonennamen und den aktuellen UTC-Offset für genau diesen Punkt zurückgibt, optional für einen bestimmten Zeitpunkt statt für jetzt berechnet.
Der IANA-Name ist wichtiger, als es klingt. Ein reiner UTC-Offset ändert sich mit Sommerzeitregeln, die sich von Land zu Land und manchmal sogar von Region zu Region innerhalb eines Landes unterscheiden. Wer „UTC+2“ in einem Kundendatensatz speichert, hat also zweimal im Jahr unbemerkt einen falschen Wert. Wird stattdessen „Europe/Warsaw“ gespeichert, wird der Offset immer korrekt für das Datum berechnet, an dem ein Ticket oder Rückruf geplant ist, weil die zugrunde liegende Zeitzonendatenbank diese Regeländerungen nachverfolgt, sobald sie eintreten.
Die sichtbare Änderung war eine kleine Zeile oben in jedem Ticket: die aktuelle Ortszeit des Kunden neben seinem Namen. Die Mitarbeiter fragten nicht mehr „Ist es bei Ihnen schon spät?“, sondern begannen Nachrichten stattdessen mit einem zutreffenden „Guten Nachmittag“. Auch die Ticketverteilung verbesserte sich, sobald die Warteschlange danach sortieren konnte, welche Kunden sich gerade innerhalb der Arbeitszeiten ihrer eigenen Region befanden, statt danach, welches Support-Team zufällig besetzt war.
Nichts davon erforderte eine von Hand gepflegte Datenbank mit Zuordnungen von Ländern zu Zeitzonen, also den Ansatz, den sich das Unternehmen vorher zusammengebastelt hatte und der jedes Mal versagte, wenn die IP eines Kunden zu einem großen Land mit mehreren Zonen aufgelöst wurde. Die Zeitzone direkt aus den Koordinaten abzulesen, beseitigte diese ganze Fehlerkategorie.
Das Volumen war gering, eine Abfrage pro neuem Ticket, deutlich innerhalb der 2.500 kostenlosen Anfragen pro Tag, die im Schlüssel des Unternehmens enthalten sind. Das Support-Tool allein kam nie auch nur in die Nähe von Prepaid-Guthaben, auch wenn derselbe Schlüssel andere Teile des Produkts abdeckte, bei denen das der Fall war.
Der Umgang mit Zeitzonen gehört zu den Details, die Kunden nur bemerken, wenn etwas falsch ist. Sie still im Hintergrund jedes Tickets richtig zu handhaben, ist eine kleine Korrektur mit überproportionaler Wirkung darauf, wie ein Support-Team wahrgenommen wird. Die Dokumentation beider Endpunkte finden Sie unter /docs/ipv4-lookup/ und /docs/timezone-lookup/.