Debian stellt ohne auf das Jahr-2038-Problem zu warten vollständig auf ein 64-Bit-Zeitsystem um

• Debian führt zur proaktiven Vermeidung des Y2K38- (Unix-Epochalypse-) Problems ab der nächsten Version Debian 13 auch auf 32-Bit-Architekturen offiziell 64-Bit-time_t ein
• Aufgrund der Grenzen des bisherigen 32-Bit-time_t könnte es nach dem 19. Januar 2038 dazu kommen, dass die Zeit auf 1900 zurückspringt; dieses Problem soll daher nicht länger aufgeschoben werden
• Zwar ist 64-Bit-Hardware bereits sicher, doch für kostenkritische 32-Bit-Geräte wie Embedded- und IoT-Systeme besteht weiterhin Nachfrage nach Debian, weshalb vorbeugende Maßnahmen nötig sind
• Es läuft eine groß angelegte Umstellung, bei der der in insgesamt 6.429 Paketen verteilte time_t-Typ unter Inkaufnahme eines ABI-Kompatibilitätsbruchs gleichzeitig migriert wird
• Einige Legacy-Architekturen wie i386 und hurd-i386 bleiben Ausnahmen, zugleich wird die mögliche Einführung einer neuen x86-Architektur (i686) auf Basis von 64-Bit-time_t erwähnt

---

Debians Reaktion auf den Y2K38-Bug: Umstellung auf 64-Bit-Zeit

• Debian stellt zur Vermeidung des bevorstehenden Y2K38- beziehungsweise Unix-Epochalypse-Problems in allen Umgebungen auf 64-Bit-Zeit um, mit Ausnahme eines Teils der ältesten noch unterstützten Hardware
• Dadurch sollen fehlerhafte Zeitwerte durch Überschreiten des 32-Bit-Signed-Int-Bereichs, die am 19. Januar 2038 auftreten würden, verhindert werden

Hintergrund zum Y2K38- und Unix-Epochalypse-Problem

• Das Y2K38-Problem tritt in Unix-Systemen auf, die die seit dem 1. Januar 1970 vergangenen Sekunden als 32-Bit-Signed-Int darstellen; nach 2038 kommt es dabei zu einem Overflow, sodass die Zeit fälschlich in die Vergangenheit, etwa ins Jahr 1900, zurückspringt
• Wie schon bei Y2K (dem Jahr-2000-Problem) liegt die Ursache in einer architektonischen Entscheidung für ein zu kurzes Datenformat
• Bei Y2K konnte dank frühzeitiger Gegenmaßnahmen der Entwickler ein großes Chaos verhindert werden
• Software für 64-Bit-Hardware ist bereits sicher, doch Debian wird weiterhin breit in Embedded-, Low-End- und Legacy-Umgebungen eingesetzt

Debians wichtigste Maßnahmen

• Ab dem Release Debian 13 "Trixie" wird 64-Bit-time_t auf allen wichtigen Architekturen als Standard aktiviert
• 64-Bit-Hardware ist bereits sicher, doch Probleme treten weiterhin oft bei Embedded-Geräten und Legacy-Hardware auf Basis von 32-Bit-Prozessoren auf
• Solche Geräte werden in kostenkritischen und in hohen Stückzahlen ausgelieferten Bereichen wie Fahrzeugsteuerung, IoT, Fernsehern und Routern weiterhin eingesetzt
• Viele neue Geräte verwenden selbst gebaute Linux-Systeme wie OpenEmbedded, Alpine, Android oder Gentoo, doch auch Debian-basierte Embedded-Geräte dürften in den kommenden Jahren weiter verbreitet bleiben

Umsetzung und Änderungen

• time_t-Variablen sind auf 6.429 Pakete verteilt, weshalb ein groß angelegter Aufwand erforderlich war
• Diese Änderung kann die ABI- (Application Binary Interface-) Kompatibilität aufbrechen, daher wurden alle betroffenen Bibliotheken und Pakete gleichzeitig angepasst
• Laut dem Maintainer-Team ist diese Arbeit abgeschlossen und ausreichend getestet

Ausnahmen und weitere Pläne

• Der i386-Port (klassisches x86) behält weiterhin 32-Bit-time_t bei und bleibt aus Gründen der Kompatibilität zur Ausführung bestehender Binärdateien erhalten
• Für die i686-Architektur könnte separat über die Einführung von 64-Bit-Zeit und einer modernen ISA (Instruction Set Architecture) diskutiert werden
• Der hurd-i386-Port wird wegen fehlender Kernel-Unterstützung nicht umgestellt; stattdessen wird an einem Wechsel zu hurd-amd64 gearbeitet

Hinweise für Entwickler

• Entwickler können mithilfe der im Debian-Wiki beschriebenen Verfahren testen, ob ihre Software durch die Einführung von 64-Bit-Zeitvariablen beeinträchtigt wird
• Weitere Details und technische Dokumentation bietet das Debian wiki

[GN⁺]

Hacker-News-Kommentare

• Steve Langasek hat in den letzten Jahren seines Lebens intensiv an der Lösung dieses Problems gearbeitet und große Fortschritte ermöglicht; jedes Mal, wenn ich künftig 64-bit time_t sehe, werde ich an ihn denken
  • Danke, dass du die gute Nachricht noch einmal in Erinnerung gerufen hast; ich vermisse Steve und frage mich, ob Joey noch bei Debian aktiv ist
• Beim Y2K-Problem, also dem Jahr-2000-Problem durch zweistellige Jahresdarstellung, war die Einsparung von 2 Byte damals äußerst wertvoll; Software aus den 70ern bis 90ern änderte sich schnell, daher erwartete man oft nicht, dass sie länger als fünf Jahre genutzt würde; die abwertende Sicht darauf wirkt unfair
  • Auch heute werden noch oft zweistellige Jahre verwendet, zum Beispiel beim Ablaufdatum von Kreditkarten (mm/yy), weil die kurze Schreibweise praktisch ist; für die Lebensdauer einer Karte reicht das aus, aber im Jahr 2100 könnte es zu Umstellungsproblemen kommen; ein Großteil von Y2K entstand durch UI-Probleme (Textfelder mit zwei Zeichen, hartkodiertes +1900 usw.); ein Y2K-Bug, den ich selbst erlebt habe, war ein Internetforum, das von 1999 auf 19100 sprang, also ein bloßer Ausgabefehler; Y2K war kein reines COBOL-Problem
  • In solchen Fällen hätte „verfrühte Optimierung“ sogar geholfen; wenn man Datumswerte einfach als int mit 0 für das Jahr 1900 gespeichert hätte, wären noch mehr Bytes eingespart worden; mit 3 Byte ließen sich Daten von 1900 bis ungefähr Tag 44.000 abdecken, mit 2 Byte sogar bis etwa 2070
  • Was viele verwechseln: Es ging nicht darum, 2 Byte hinzuzufügen, sondern 2 Zeichen mehr unterzubringen; in COBOL wurden Zahlen wie Daten generell mit fester Breite entsprechend der Zeichenzahl zugewiesen, also brauchte ein vierstelliges Jahr vier Zeichenpositionen; solche Feldgrößen waren im gesamten Programm hartkodiert, beim Datenzugriff, in der UI, in Batch-Dateien, Zwischen-Dateien und Transferdateien
  • Kurz vor Y2K gab es Bekannte, die einen Kurseinbruch großer Banken erwarteten und massenhaft Put-Optionen kauften, aber tatsächlich passierte fast nichts Großes
  • Ich habe Ende der 80er mit COBOL an einem Programm gearbeitet, das nur eine einstellige Jahreszahl speicherte; als mir die Struktur erklärt wurde, fand ich das seltsam, aber die Datensätze wurden ohnehin alle vier Jahre automatisch gelöscht, sodass es im Betrieb kein Problem gab; es war immer klar, welches Jahr gemeint war
• time_t mit 64 Bit wird die Epochalypse lösen, aber nicht alle Systeme gehen einfach zu 64-Bit-Sekunden über; ext4 verwendet bereits 30 Bit für die Nachkommengenauigkeit auf Bruchteilebene (Nanosekundenbereich) und 34 Bit für Sekunden, aber in einigen hundert Jahren wird das Problem dennoch wieder auftreten; vermutlich landen wir irgendwann bei 128-Bit-Zeitstempeln mit 64-Bit-Sekunden plus 64-Bit-Bruchteil, womit sich praktisch die gesamte für die Menschheitsgeschichte absehbare Zukunft abdecken ließe
  • 64-Bit-Sekunden entsprechen ungefähr 585 Milliarden Jahren, laut WolframAlpha
  • Selbst 64 Bit für die Bruchteilauflösung könnten nicht reichen; um in die Nähe der Planck-Zeit zu kommen, bräuchte man bis zu 144 Bit
  • Ich hatte mich schon gefragt, wie ext4-Zeitstempel aussehen; jetzt bin ich auch neugierig, wie zfs und btrfs Zeit behandeln; btrfs nutzt vermutlich 64 Bit, und ich erwarte, dass zfs ähnlich funktioniert (vielleicht verwechsle ich es mit ext4)
• Es heißt, Debian behebe Y2K38, also das Unix-Epochalypse-Problem, aber tatsächlich ist auf allen 32-Bit-Ports außer i386 die Umstellung auf time64_t bereits abgeschlossen; nur i386 ist wegen der bestehenden Binärkompatibilität ausgenommen, alle anderen wurden umgestellt, einschließlich m68k; ich selbst habe m68k, powerpc, sh4 und hppa migriert
• time_t ist keine Variable, sondern ein Datentyp
  • Das im Artikel Genannte basiert auf dem Debian-Wiki; dort steht ausdrücklich: „time_t taucht wirklich überall auf. Es erscheint im Quellcode von 6.429 der 35.960 Pakete. Pakete, die Strukturen mit time_t als ABI exportieren, müssen eine vollständige ABI-Migration gleichzeitig durchführen.“ Das Wiki erklärt es klarer als der Artikel
  • Bei „For everything“ sind armel, armhf, hppa, m68k, powerpc und sh4 gemeint, aber nicht i386; i386 hat keine Zukunft mehr, sein Hauptzweck ist das Ausführen bestehender Binärdateien und dynamischer Bibliotheken, daher will man es nicht kaputtmachen
  • „Zur Anwendung nach der Veröffentlichung von Debian 13 Trixie vorgesehen“ bedeutet in Wirklichkeit, dass es in Trixie enthalten ist
• Es wäre schön, wenn man auch die Längenbegrenzung der Kommandozeile unbegrenzt oder dynamisch machen könnte; trotz 96 GB RAM ist der Fehler argument list too long häufig lästig
  • Man kann den Kernel neu kompilieren und das Limit für die Befehlszeilenlänge (etwa 100.000 Zeichen) aufheben, siehe Stack Overflow, aber das wirkt nicht wie eine grundlegende Lösung; wofür man Argumente in der Länge eines 4k-JPEGs brauchen sollte, ist fraglich
  • Es reicht, RLIMIT_STACK zu erhöhen, zum Beispiel ergibt ulimit -s 4000 einen Stack von 4 MB; für noch mehr muss man /etc/security/limits.conf ändern und sich neu anmelden
  • Vielleicht könnte man es in Electron verpacken und per HTTP-POST als JSON-Anfrage übergeben
  • Man kann MAX_ARG_STRLEN neu definieren und den Kernel neu kompilieren; eine weitere Möglichkeit ist eine Maschine mit größerer Seitengröße, etwa ein RHEL-Arm-Kernel mit 64k Seitengröße; trotzdem ist es viel einfacher, statt eines Kommando-Puffers Pipes für den Datenaustausch zwischen Prozessen zu verwenden
  • Dasselbe gilt für Pfadlängenbeschränkungen; bei manchen Build-Systemen (Debian + python + dh-virtualenv usw.) können Pfade extrem lang werden, und es wäre bequemer, das einfach zuzulassen
• Auch mit 64 Bit wird es irgendwann wieder eine Grenze geben; ich frage mich, was die Menschheit am 4. Dezember 292277026596 um 15:30:07 UTC tun wird
  • Wahrscheinlich feiert sie dann gerade den 100. Jahrestag der vollständigen Einführung von ipv6
  • Innerhalb der nächsten 5 Milliarden Jahre wird die Sonne zum Roten Riesen und die gesamte Erdoberfläche verdampfen
  • Bis dahin sollten wir hoffentlich zu einem besseren Kalendersystem gewechselt haben, auch wenn das Zeitstempelproblem dann weiterhin bleibt
  • Dann gehen wir eben zu 128-Bit-Zeit über
  • Vielleicht ließe sich RFC 2550 (Y10K & beyond) anwenden; veröffentlicht wurde es am 1. April 1999
• OpenBSD 5.5 hat dieselbe Änderung bereits vor 11 Jahren eingeführt, siehe die Release Notes von OpenBSD 5.5
  • Damit haben sie alle geschlagen; ich habe schon in den 90ern entdeckt, dass die 32-Bit-API von OS/2 64-Bit-Zeit zurückgibt, und dann selbst die C++-Standardbibliothek mit 64-bit time_t geschrieben und verwendet
  • Etwas anderes Thema, aber in solchen Zeiten bekomme ich Lust, meine Server statt auf Linux auf OpenBSD umzustellen
  • OpenBSD muss weniger auf Kompatibilität Rücksicht nehmen, und es hat viel weniger Nutzer, wodurch bei Änderungen die Wahrscheinlichkeit für Bugs oder Edge Cases sinkt
• Wenn es heißt: „Debian ist nun ausreichend fertiggestellt und getestet, sodass die Umstellung nach dem Release von Trixie erfolgen soll“, bedeutet das dann, dass es nicht in Trixie enthalten ist?
  • In den Trixie-Release-Notes steht, dass es enthalten ist, siehe hier
• Ich höre zum ersten Mal, dass Y2K38 als Unix Epochalypse bezeichnet wird, aber es ist niedlich genug, dass es sich vielleicht verbreitet
  • Auch im Wikipedia-Artikel zum Year 2038 Problem taucht der Name auf; seit 2017 verbreitet er sich als scherzhafte Bezeichnung
  • Es gibt auch das Projekt epochalypse-project.org
  • In der Formulierung „it’s kind of fetch“ steckt offenbar eine Anspielung auf den Film Mean Girls
  • Bis zur Epochalypse sind es noch ungefähr 12 Jahre, 5 Monate, 22 Tage, 13 Stunden und 22 Minuten