Eine Zeitzone ist eine politische Entscheidung, bevor sie eine geografische ist. Die Grenze zwischen zwei Zonen, die Entscheidung, die Sommerzeit einzuhalten, und das genaue Datum, an dem die Uhr vor- oder zurückgestellt wird, werden alle von nationalen oder lokalen Regierungen festgelegt, und jede davon kann sich ändern. Deshalb können Zeitzonendaten keine statische Tabelle von Zeitverschiebungen sein, die zu einem Zeitpunkt in der Vergangenheit eingefroren wurde. Sie müssen eine gepflegte Aufzeichnung der Geschichte, der aktuellen Regeln und bekannter künftiger Änderungen sein.
Die IANA-Zeitzonendatenbank ist genau aus diesem Grund die Referenz, auf die sich die meiste Software stützt. Ihre Betreuer verfolgen Änderungen der gesetzlichen Zeit, sobald Regierungen sie ankündigen, ob es sich um eine geänderte Sommerzeitregelung handelt, um eine Änderung der UTC-Verschiebung, die eine Region einhält, oder um eine Grenzanpassung zwischen Zonen innerhalb eines Landes. Jede benannte Zone, etwa Europe/Amsterdam oder America/Chicago, enthält nicht nur eine aktuelle Regel, sondern die vollständige Geschichte früherer Regeln, denn Software muss oft die korrekte Verschiebung für ein Datum in der Vergangenheit berechnen, nicht nur für heute.
Diese Geschichte ist wichtiger, als es scheinen mag. Ein Zeitstempel von vor einigen Jahren braucht die Verschiebung, die an diesem Datum tatsächlich galt, und die kann sich von der heute geltenden unterscheiden, wenn sich die Regeln zwischendurch geändert haben. Eine Zeitzonenabfrage, die nur die aktuelle Regel kennt, liefert für vergangene oder künftige Daten stillschweigend falsche Ergebnisse. Deshalb lohnt es sich immer, wenn das Datum eine Rolle spielt, eine Zeitzonen-API nach der Zone zu einem bestimmten Zeitpunkt zu fragen und nicht nur nach dem Zonennamen.
Aus demselben Grund sollte eine Zeitzonenabfrage den tatsächlichen Zonennamen zurückgeben und nicht nur eine numerische Verschiebung. Europe/Amsterdam trägt die gesamte Geschichte und Sommerzeitlogik in sich. +01:00 ist nur für einen Teil des Jahres korrekt und sagt nichts darüber aus, wann es sich ändert. Software, die für einen Ort nur die Verschiebung speichert, wird bei der nächsten Sommerzeitumstellung unkorrekt, während Software, die den Zonennamen speichert, auf unbestimmte Zeit korrekt bleibt, solange die zugrunde liegende Datenbank aktuell gehalten wird.
Die Zeitzonenabfrage von My Geocode gibt den IANA-Zonennamen und die UTC-Verschiebung zusammen zurück und akzeptiert einen bestimmten Zeitpunkt, sodass die korrekte Verschiebung einschließlich Sommerzeit für genau dieses Datum gilt, statt anzunehmen, dass die heutige Regel schon immer galt.
Eine Adresse in einem gut kartierten Stadtzentrum sagt Ihnen fast nichts darüber, wie Ihr System mit einer ländlichen Zustellroute, einer umstrittenen Grenze oder einer Anfrage in Polnähe umgeht. Testen Sie die schwierigen Fälle gezielt.
Nicht jeder Datensatz mit öffentlich wirkenden Standortinformationen darf rechtlich in einem kostenpflichtigen Produkt verwendet werden. Die eigentliche Grenze setzen oft die Lizenzbedingungen, nicht die technische Verfügbarkeit.
Wenn sich eine Anfrage wirklich nicht zuverlässig auflösen lässt, ist es die bessere Antwort, nichts zurückzugeben, statt eine als Tatsache verkleidete Vermutung. Hier ist die Begründung für diese Entscheidung.