Das Jahr-2038-Problem (Y2K38) erklärt
Am 19. Januar 2038 um 03:14:07 UTC läuft der Unix-Timestamp 2.147.483.647 — der Maximalwert einer vorzeichenbehafteten 32-Bit-Ganzzahl — über. Hier steht, was das bedeutet, welche Systeme betroffen sind und warum der meiste moderne Code bereits sicher ist.
Was ist das Jahr-2038-Problem?
Unix-Timestamps werden traditionell als vorzeichenbehaftete 32-Bit-Ganzzahl gespeichert, die Sekunden seit dem 1. Januar 1970 00:00:00 UTC zählt. Der Maximalwert einer vorzeichenbehafteten 32-Bit-Ganzzahl ist 2,147,483,647 — das entspricht dem 19. Januar 2038 um 03:14:07 UTC. Eine Sekunde später läuft die Ganzzahl auf -2,147,483,648 über. Als Unix-Timestamp interpretiert entspricht dieser negative Wert dem 13. Dezember 1901 und schickt betroffene Systeme fast 137 Jahre in die Vergangenheit.
Die Überlaufwerte
- 2^31 − 1 = 2,147,483,647 (maximale vorzeichenbehaftete 32-Bit-Ganzzahl)
- 2,147,483,647 als Datum = 19. Januar 2038 03:14:07 UTC
- 2,147,483,647 + 1 läuft über auf −2,147,483,648 (der negativste 32-Bit-Wert)
- −2,147,483,648 als Datum = 13. Dezember 1901 20:45:52 UTC
Welche Systeme sind gefährdet?
Das Problem betrifft Systeme, die Timestamps als vorzeichenbehaftete 32-Bit-Ganzzahlen speichern:
- Embedded-Systeme und Mikrocontroller mit 32-Bit-time_t
- Alter C- und C++-Code, der für 32-Bit-Ziele kompiliert wurde und time_t oder int für Timestamps nutzt
- Alte Linux-Kernel (vor 5.6) auf 32-Bit-Hardware, die noch in Produktion sind
- MySQL-TIMESTAMP-Spalten — auf 2038-01-19 begrenzt; nutze stattdessen DATETIME
- Manche Netzwerkprotokolle und Dateiformate, die Timestamps als 32-Bit-Werte kodieren
- Firmware in industriellen Steuerungssystemen und IoT-Geräten mit jahrzehntelanger Lebensdauer
Welche Systeme sind sicher?
Der meiste moderne Code und die meiste Infrastruktur sind bereits nicht betroffen:
- Jedes 64-Bit-Betriebssystem — Linux (glibc 2.34+ behebt auch 32-Bit-Hardware), macOS, Windows
- Python — Timestamps nutzen 64-Bit-Floats, sicher weit über das Jahr 292 Millionen hinaus
- JavaScript — Date nutzt 64-Bit-IEEE-754-Floats, sicher bis zum Jahr 275,760
- Go und Rust — nutzen intern int64, sicher für Milliarden von Jahren
- Java — java.time.Instant nutzt long (64 Bit), sicher bis zum Jahr ~292 Millionen
- PostgreSQL TIMESTAMP — speichert Daten über 2038 hinaus korrekt
- MySQL DATETIME — Bereich 1000-01-01 bis 9999-12-31, nicht betroffen
FAQ zum Jahr-2038-Problem
- Was ist das Jahr-2038-Problem?
- Das Jahr-2038-Problem (Y2K38) ist ein Fehler, bei dem Systeme, die vorzeichenbehaftete 32-Bit-Ganzzahlen zum Speichern von Unix-Timestamps verwenden, am 19. Januar 2038 um 03:14:07 UTC überlaufen. Der Maximalwert einer vorzeichenbehafteten 32-Bit-Ganzzahl ist 2,147,483,647. Eine Sekunde später springt die Ganzzahl auf -2,147,483,648, was dem 13. Dezember 1901 entspricht.
- Was ist der Unix-Timestamp für den 19. Januar 2038?
- Der Unix-Timestamp für den 19. Januar 2038 um 03:14:07 UTC ist 2,147,483,647 — der Maximalwert einer vorzeichenbehafteten 32-Bit-Ganzzahl (2^31 - 1). Das ist der exakte Moment, in dem der Jahr-2038-Überlauf auf 32-Bit-Systemen auftritt.
- Ist Y2K38 dasselbe wie Y2K?
- Nein. Y2K (Jahr-2000-Problem) entstand durch Programme, die Jahre zweistellig speicherten. Y2K38 entsteht durch das Speichern von Unix-Timestamps als vorzeichenbehaftete 32-Bit-Ganzzahlen, die 2038 überlaufen. Andere Ursachen, andere betroffene Systeme.
- Bricht das Internet 2038 zusammen?
- Wahrscheinlich nicht nennenswert. Der Großteil der Internet-Infrastruktur ist bereits auf 64-Bit-Systeme migriert. Das Risiko konzentriert sich auf Embedded-Systeme, alte IoT-Geräte und seit Jahrzehnten nicht aktualisierte Software. Moderne Betriebssysteme, Sprachen und Datenbanken sind bereits sicher.