Die Datumsgrenze und das Jahr-2038-Problem, zwei kuriose Zeit-Phänomene

Zwei der kuriosesten Eigenheiten der globalen Zeit sind die Internationale Datumsgrenze und das Jahr-2038-Problem. Die erste ist eine geographische Anomalie, die das Reisen im Pazifik in eine kleine Zeitreise verwandelt. Die zweite ist eine technische Bombe, die 1970 unbewusst gelegt wurde und 2038 hochgehen könnte. Beide sind das Ergebnis menschlicher Festlegungen, die spätere Generationen ungläubig anschauen werden.

Die Datumsgrenze als physisches Phänomen

Die Internationale Datumsgrenze (IDL, International Date Line) verläuft etwa entlang des 180. Längengrads im Pazifik. Wer sie von Westen nach Osten überquert, verliert einen Tag. Wer sie von Osten nach Westen überquert, gewinnt einen Tag. Es ist die einzige Linie auf der Welt, an der sich das Datum unmittelbar ändert.

In der Praxis sind die Folgen erstaunlich konkret. Ein Flug von Auckland (UTC+12) nach Honolulu (UTC-10) dauert etwa 9 Stunden, der Reisende kommt aber 5 Stunden vor seinem Abflug an, lokal gerechnet. Ein Geschäftsreisender, der montags um 18:00 in Auckland startet, landet montags um 13:00 in Honolulu. Der Tag wird quasi noch einmal gelebt.

Die IDL folgt nicht streng dem 180. Meridian. Sie wurde mehrfach politisch verschoben, um wirtschaftliche Räume nicht zu trennen. Die wichtigsten Ausbuchtungen:

• Kiribati (1995): Verschiebung der IDL um 30 Längengrade nach Osten. Vorher lag das Land beidseits der Grenze (also halb Montag, halb Sonntag), seit 1995 komplett auf der westlichen Seite. Kiribati feierte das neue Jahrtausend 2000 als erstes Land der Erde.
• Samoa (2011): Wechselte von UTC-11 zu UTC+13, sprang also einen Tag nach vorne. Hintergrund: wirtschaftliche Anpassung an Australien und Neuseeland statt USA. Der 30. Dezember 2011 wurde in Samoa „übersprungen".
• Tokelau (2011): Folgte Samoa eine Woche später, sprang ebenfalls einen Tag.

Heute liegt die IDL teilweise weit östlich vom 180. Meridian, insbesondere in der Kiribati-Region. Maps-Visualisierungen, die die Grenze als gerade Linie zeigen, sind veraltet.

Was die IDL für Reisende bedeutet

Drei pragmatische Konsequenzen.

Bei Buchungen prüfen: Manche Buchungssysteme rechnen falsch um die IDL. Vor allem Flüge zwischen Hawaii und Auckland, oder zwischen Tahiti und den Cook-Inseln. Wer einen Anschluss innerhalb von wenigen Stunden hat, sollte das Ankunftsdatum genau verifizieren.

Versicherungs- und Visum-Daten: Eine Reiseversicherung mit „Geltung ab 1. Januar 8:00 Uhr deutscher Zeit" hat in Auckland bereits am 1. Januar 21:00 Uhr ihre Gültigkeit. Wer am 31. Dezember spät reist und auf der falschen Seite der IDL landet, kann ohne Schutz unterwegs sein. Klar mit der Versicherung absprechen.

Bürokratisches Datum: Wer am 30. Dezember in Auckland geboren wird und am 30. Dezember (lokal Hawaii) am gleichen Tag in einem US-Krankenhaus liegt, hat juristisch zwei verschiedene Geburtsdaten. Solche Fälle sind selten, aber existieren in Adoptions- und Familien-Kontexten.

Das Jahr-2038-Problem

Im Januar 1970 wurde das Unix-Betriebssystem entwickelt. Eine Designentscheidung war, Zeit als Anzahl Sekunden seit Mitternacht UTC am 1. Januar 1970 zu speichern. Diese Variable, der „Unix-Timestamp", wurde standardmäßig als 32-Bit signed integer implementiert. 32-Bit signed bedeutet einen Wertebereich von -2.147.483.648 bis +2.147.483.647.

Der maximale Wert entspricht dem 19. Januar 2038, 03:14:07 UTC. In diesem Moment springt der Wert (in einer 32-Bit-Variable) auf -2.147.483.648, was das Datum 13. Dezember 1901 ergibt. Software, die diese Variable als „aktuelle Zeit" interpretiert, denkt plötzlich, sie befinde sich im Jahr 1901.

Wer ist betroffen

Das Y2038-Problem trifft nicht alles. Drei Kategorien.

Sicher (64-Bit-Systeme): Praktisch alle modernen Linux-, macOS- und Windows-Server, alle aktuellen Smartphones, alle Cloud-Dienste, alle größeren Datenbanken. 64-Bit signed integer reicht für etwa 292 Milliarden Jahre, das Problem stellt sich nicht.

Riskant (Embedded Systems): Geräte mit 32-Bit-CPUs, die seit ca. 2010 nicht aktualisiert wurden. Internet-of-Things-Geräte (alte Smart-Plugs, manche Router), Industrie-Steuerungen, älteres Auto-Multimedia, Heizungs-Thermostat-Computer. Viele dieser Systeme rechnen mit 32-Bit-Timestamps und werden 2038 fehlschlagen.

Definitiv betroffen (alte Spezial-Software): Banken-Backend-Systeme, die noch in COBOL oder C aus den 1980ern laufen. Manche behördliche Datenbanken in Deutschland und Frankreich. Maritime und Luftfahrt-Systeme mit alten Hardware-Komponenten. Diese werden bis 2038 schrittweise migriert, aber der Aufwand ist erheblich.

Was bisher unternommen wurde

Die Linux-Kernel-Entwickler haben das Problem 2014 angegangen und in modernen Kernel-Versionen ist es behoben. POSIX-Konforme Programmiersprachen (C, C++, Python) haben ebenfalls 64-Bit-Time-Funktionen. Java nutzte schon seit Java 8 (2014) eine eigene Zeit-API ohne 32-Bit-Limit.

Das Problem ist nicht in der Sprache, sondern in alten Software-Systemen, die nie aktualisiert werden. Anders als das Y2K-Problem (Jahr 2000), das eine konzertierte Welt-Aktion mit Jahren Vorlauf hatte, ist das Y2038-Problem dezentralisiert. Jeder System-Betreiber muss seine eigenen Systeme prüfen.

Ein Test, den du selbst machen kannst

In einer Linux-Konsole oder einem Online-Compiler:

// C-Code, 32-Bit-Compilation
#include <stdio.h>
#include <time.h>
int main() {
    time_t t = 2147483647;  // Max Wert
    printf("%s", ctime(&t));
    t++;  // Overflow
    printf("%s", ctime(&t));
    return 0;
}

Auf einem 64-Bit-System läuft das ohne Problem (Ergebnis: 19. Januar 2038, dann 19. Januar 2038 plus eine Sekunde). Auf einem 32-Bit-System springt der zweite Print zu „13. Dezember 1901". Wer einen alten Raspberry Pi oder einen 32-Bit-Server verfügbar hat, kann das selbst sehen.

Quellen

• USNO: The Origin of the International Date Line
• The Linux Foundation: Y2038 Problem and Linux Kernel Mitigation
• Samoa Government: International Date Line Decision 2011
• POSIX: time_t Definition and Future Compatibility