Jahr-2038-Problem

Kern des Problems

Das Jahr-2038-Problem (Y2K38) betrifft EDV-Systeme, die die Unixzeit als vorzeichenbehaftete 32-Bit-Ganzzahl speichern. Die Unixzeit zählt Sekunden seit dem 1. Januar 1970. Ihr höchster darstellbarer Wert ist 2.147.483.647 beziehungsweise 2^{31}−1. Am Dienstag, 19. Januar 2038, um 03:14:07 Uhr UTC wird dieser Wert überschritten.

Dann führt das Vorzeichenbit im Zweierkomplement dazu, dass der Zähler von 01111111 11111111 11111111 11111111 auf −2.147.483.648 beziehungsweise 10000000 00000000 00000000 00000000 springt. Eine unzureichende Umrechnung von Unixzeit in Datum und Uhrzeit kann dies als Freitag, 13. Dezember 1901, 20:45:52 Uhr UTC deuten. Dies ist ein Zählerüberlauf und kann falsche Zeitstempel, Fehlfunktionen und Ausfälle verursachen.

Betroffene Systeme und typische Folge

Besonders relevant sind weiterhin eingesetzte 32-Bit-Unix- und Unix-artige Systeme mit ABI-Kompatibilität zu UNIX beziehungsweise POSIX. Zwar gilt der Wechsel zu 64-Bit bei Servern und PCs als weitgehend abgeschlossen, doch eingebettete Systeme werden oft viel länger betrieben. Dazu zählen etwa Router, elektronische Messgeräte, Automobil-Systeme, IoT-Geräte, Fernsehgeräte sowie Anlagen- und Gebäudeüberwachung oder -steuerung. Auch nach einer Portierung auf 64 Bit können Fehler bleiben, wenn Zeitstempel nicht vollständig geprüft oder nur als 32-Bit-Werte weiterverarbeitet werden.

Ein Beispiel ist eine Gültigkeitsprüfung mit Zeitstempeln, etwa die automatische Abmeldung beim Onlinebanking nach wenigen Minuten. Wird die Startzeit gespeichert und springt der Zeitstempel währenddessen auf das Jahr 1970, bleibt die Zeitdifferenz negativ. Wartet ein Programm auf eine positive Differenz von mindestens beispielsweise 5 Minuten, erreicht es den Zielwert nicht. Sicherheitszugänge können dadurch zu lange offen bleiben; auch Endlosschleifen und scheinbares Nichtreagieren des Programms sind möglich.

Umstellung auf größere Zeitwerte

Eine zentrale Abhilfe ist ein 64-Bit-time_t. Beim Unix-Übergang von 32 auf 64 Bit wurde dafür häufig der C-Basistyp „long“ von 32 auf 64 Bit erweitert: vom ILP32- zum LP64-Modell. Ein POSIX-Zeitstempel mit 64-Bit-Sekunden seit dem 1. Januar 1970 reicht für 292 Milliarden Jahre.

Ein 64-Bit-Prozessor allein genügt jedoch nicht. Programme mit fester 32-Bit-Formatierung müssen durchsucht und neu übersetzt werden. Andernfalls können sie vom 64-Bit-Zeitstempel nur die niederwertigen 32 Bits verwenden; diese nehmen am 19. Januar 2038 wieder den Wert −2^{31} und damit den 13. Dezember 1901 an. Auch 32-Bit-Programme auf Multilib-Systemen können wegen ABI-Kompatibilität weiter betroffen sein.

Einige Systeme stellten time_t auch auf 32-Bit-Architekturen auf 64 Bit um: NetBSD ab Version 6.0 (2012), OpenBSD ab Version 5.5 (2014) und der Linux-Kernel ab Version 5.6 (2020). Die GNU-C-Bibliothek führte für einzelne Programme time64_t ein; unter Windows gibt es __time64_t, und Visual C++ 2005 setzte time64 als Standard. Debian GNU/Linux kündigte 2024 die vollständige Umstellung bestehender 32-Bit-Ports wie ARMv7 an, ausgenommen i386 und i386-hurd. Das Linux-ABI „x32“ läuft im nativen 64-Bit-Modus; time_t bleibt dort 64-bittig.

Andere Zeitbasen und Zeichenketten

Programme können statt Unixzeit andere Zeitbasen verwenden. 64-Bit-Zähler für Millisekunden oder Mikrosekunden sind besonders bei eingebetteten Echtzeitsystemen verbreitet und benötigen nicht zwingend eine 64-Bit-Architektur. Java System.currentTimeMillis zählt 64-Bit-Millisekunden seit dem 1. Januar 1970 und reicht für 292 Millionen Jahre. .NET System.DateTime.Now.Ticks zählt 64-Bit-Zehntel-Mikrosekunden seit dem 1. Januar 0001 und reicht für 29227 Jahre.

Datenbanktransaktionen verwenden häufig TIMESTAMP-Werte nach SQL92 mit Mikrosekundengenauigkeit. Ihre Darstellung erfolgt meist über einen Abstand zu einem Tageszähler (SQL DATE), dessen 32-Bit-Spannweite größer ist. Werden solche Datentypen durchgängig verwendet, entfällt die Beschränkung des Unixzeit-Zählers.

Zeitstempel können auch gemäß ISO 8601 als Zeichenkette YYYYMMDDhhmmss gespeichert werden, zum Beispiel „20140823142216“. Dies vermeidet Jahresüberläufe mindestens bis zum 31. Dezember 9999, 23:59:59 Uhr, solange interne Berechnungen die Werte nicht wieder in ein problematisches Binärformat umwandeln.

Verwandtes Problem im Jahr 2036

Das Jahr-2036-Problem (Y2K36) betrifft den Zähler des ursprünglich für UNIX entwickelten Zeitsynchronisationsprotokolls NTP (Network Time Protocol). Dieser läuft am Donnerstag, 7. Februar 2036, um 06:28:16 Uhr UTC über. Moderne Implementierungen beheben das Problem nach RFC 5905; viele, besonders eingebettete Geräte, arbeiten laut Artikel jedoch noch nach dem alten Standard RFC 868.

Hier wird die Zeit als vorzeichenlose 32-Bit-Sekundenzahl seit dem 1. Januar 1900, 00:00:00 Uhr UTC übertragen. Bei einer ordentlichen Implementierung soll die Zeitsynchronisation mit Differenzen rechnen, sodass kein größeres Problem entsteht. Fehler können aber auftreten, wenn Systeme sowohl NTP- als auch Unixformat verwenden. IoT-Geräte ohne batteriegestützte Echtzeituhr fragen nach jedem Start Zeitserver ab und wandeln anschließend in Unixzeit um. Schlagen Verbindungsversuche fehl und wird die Zeit mit 0 beziehungsweise 1900-01-01 00:00:00 UTC angegeben, können ungesicherte Umrechnungen einen ungültigen, bei vorzeichenbehafteter Darstellung auch negativen Unixwert erzeugen – mit ähnlichen Folgen wie beim Jahr-2038-Problem.