Datenqualität

Die Datumsgrenze und die Anfragen, die sie überqueren

Stehen Sie nur ein kurzes Stück von der Datumsgrenze entfernt, kann Ihr Nachbar auf der anderen Seite dieser Linie durchaus ein anderes Kalenderdatum erleben als Sie, obwohl Sie beide ungefähr dieselbe Ortszeit auf der Uhr sehen und sich räumlich nahe sind. Das ist eine der wirklich verwirrenderen Tatsachen darüber, wie die Zeitmessung der Welt organisiert ist, und sie hat reale, praktische Folgen für jede datumsabhängige Logik, die in ihrer Nähe arbeitet.

Die Datumsgrenze existiert, weil sich die Zeitzonen rund um den Globus aufaddieren, bis sie sich irgendwo treffen, und nach langjähriger Konvention verläuft dieser Treffpunkt ungefähr entlang des 180. Längengrads im Pazifik. Er ist bewusst so weit wie praktikabel durch offenes Meer und um bewohntes Land herum geführt, um möglichst wenige Orte direkt auf den Sprung zu legen. Wer sie in der einen Richtung überquert, setzt sein Kalenderdatum um einen Tag zurück. Wer sie in der anderen Richtung überquert, setzt es um einen Tag vor. Das kommt getrennt und zusätzlich zu dem gewöhnlichen Unterschied der Zeitverschiebung hinzu, den man beim Überqueren jeder anderen Zeitzonengrenze erwarten würde.

Für die meisten Anwendungen spielt das schlicht nie eine Rolle, denn die Datumsgrenze verläuft größtenteils durch das Meer, und die Zahl der Menschen und Unternehmen direkt an ihrem Rand ist gering. Zu einem echten Thema wird sie speziell für Anwendungen in den pazifischen Inselstaaten und -gebieten nahe der Linie, wo ein Planungssystem, eine Buchungsplattform oder alles, was berechnet, „welcher Tag gerade an diesem Ort ist“, den genauen Verlauf der Datumsgrenze richtig erfassen muss und nicht nur die allgemeine Zeitverschiebung. Andernfalls berechnet es für Orte sehr nahe an der Linie ein plausibel wirkendes, aber falsches Kalenderdatum.

Genau deshalb ist eine richtige Zeitzonenabfrage, die an die tatsächliche IANA-Zone eines bestimmten Orts gebunden ist, hier wichtiger als fast überall sonst. Eine naive Berechnung, die rein auf dem Längengrad und einer einfachen Formel für die Zeitverschiebung beruht, wird die Datumsgrenze falsch erfassen, denn der tatsächliche Verlauf der Linie weicht an mehreren Stellen bewusst von einem geraden Längengrad ab, um manche Inselstaaten und -gebiete auf einem einheitlichen Datum zu halten, statt sie ungeschickt über die Linie aufzuteilen.

Wenn Ihre Anwendung irgendwo in der Nähe des Pazifiks arbeitet und Daten, nicht nur Uhrzeiten, anhand des Standorts berechnet, verwenden Sie eine richtige Zeitzonenabfrage, die an die tatsächliche Zone dieser Koordinate gebunden ist, statt das Datum direkt aus dem Längengrad abzuleiten. Testen Sie ausdrücklich gegen Orte, die bekanntermaßen nahe an der Datumsgrenze liegen, statt anzunehmen, dass Ihre allgemeine Zeitzonenbehandlung diesen speziellen Grenzfall automatisch korrekt abdeckt.