Technik

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

Wer von Auckland nach Honolulu fliegt, landet nach Ortszeit vor dem Abflug. Am 19. Januar 2038 läuft ein 32-Bit-Zeitzähler über. Was beides bedeutet.

7 Min. Lesezeit Zuletzt geprüft:
Jan-Tristan Rudat

Von Jan-Tristan Rudat

Redakteur zeitzonen-rechner.de

Veröffentlicht am Zuletzt geprüft am

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, dessen Datum springt einen Tag zurück, ein Kalendertag wird also noch einmal erlebt. Wer sie von Osten nach Westen überquert, dessen Datum springt einen Tag vor. 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, im neuseeländischen Winter) nach Honolulu (UTC-10) dauert etwa 9 Stunden, der Reisende kommt aber 13 Stunden vor seinem Abflug an, lokal gerechnet. Ein Geschäftsreisender, der montags um 18:00 in Auckland startet, landet montags um 05:00 in Honolulu. Der Tag wird quasi noch einmal gelebt. Während der neuseeländischen Sommerzeit (UTC+13) sind es 14 Stunden.

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): Übersprang wie Samoa den 30. Dezember 2011, vollzog den Wechsel laut tz-Datenbank aber eine Stunde später (Samoa am 30.12. um 10:00 UTC, Tokelau um 11:00 UTC).

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 Tonga und Amerikanisch-Samoa. 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 20: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 früh in Auckland geboren wird, ist nach Ortszeit in Honolulu noch am 29. Dezember geboren. Solche Unterschiede spielen selten eine Rolle, können aber bei Dokumenten und Fristen auffallen.

Das Jahr-2038-Problem

Das Unix-Betriebssystem entstand ab 1969. 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.

Besonders gefährdet (alte Spezial-Software): Banken-Backend-Systeme, die noch in COBOL oder C aus den 1980ern laufen. Je nach Betreiber auch Datenbanken in Verwaltung und Industrie. 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

Häufige Fragen

Wann ist man genau "auf der falschen Seite" der Datumsgrenze?

Sobald man östlich vom 180. Längengrad fährt (oder fliegt) und die effektive IDL überschreitet. In der Praxis Pazifik zwischen Polynesien und Mikronesien. Schiffe und Flüge bekommen das Datum vom Bord-System gestellt, mit Hinweis auf die Überquerung.

Welche Geräte sind sicher vor dem Y2038-Bug?

Praktisch alles, was nach 2015 gebaut wurde und ein modernes Betriebssystem nutzt. Aktuelle Linux-, Windows-, macOS-Systeme, alle modernen Smartphones, alle Cloud-Plattformen. Risiko gibt es bei IoT-Geräten und Industrie-Steuerungen mit 32-Bit-CPUs.

Was passiert konkret in einem Banking-System mit Y2038-Bug?

Datums-bezogene Berechnungen (Zinslauf, Vertragsende, Schaltjahr-Berechnung) fallen aus oder ergeben nonsensische Werte. Seit 2008 reichen neu abgeschlossene 30-Jahres-Verträge über den Januar 2038 hinaus, 32-Bit-Berechnungen dafür sind also schon heute betroffen. Im Mai 2006 stürzte außerdem der Webserver AOLserver ab, weil er Wartezeiten von einer Milliarde Sekunden in die Zukunft setzte.

Sollte ich mein altes IoT-Gerät jetzt austauschen wegen Y2038?

Nein, panisch nicht. 2038 ist gut 11 Jahre entfernt, das Gerät wird ohnehin vorher ersetzt. Bei größeren Investitionen (Heizungssteuerung, Industrie-PC, Embedded-Auto-Computer) explizit fragen ob 32-Bit oder 64-Bit Zeit-Implementation, das ist heute Standard-Frage bei der Beschaffung.

Hat das Y2K-Problem von 2000 echten Schaden angerichtet?

Wenig sichtbarer Schaden, weil weltweit etwa 300 Milliarden US-Dollar in Vorbereitung investiert wurden. Manche Journalisten argumentieren, das Problem wurde überdimensioniert. Die meisten IT-Experten sagen, dass die Investition den katastrophalen Ausfall verhinderte.

Anzeige

UTC und Offsets im Klartext

Der Zeitzonen-Rechner zeigt jede Umrechnung als UTC-Offset und IANA-Identifier, hilfreich für Software-Spec und Doku.

Anzeige
Anzeige
Anzeige
Anzeige