Wie einst beim Millennium im Jahr 2000 steht erneut eine gewaltige technische Herausforderung bevor. Am 19. Januar 2038 um 03:14 UTC kommt es zu einem Zählerüberlauf, dem sogenannten Y2K38 Bug. Dadurch können Systeme Zeitwerte nicht mehr korrekt verarbeiten. Die Folgen reichen von fehlerhaften Berechnungen bis hin zu Ausfällen in Infrastruktur, Netzwerken und Steuerungen, überall dort, wo Software läuft. Betroffen sind nicht einzelne Systeme, sondern potenziell Milliarden von Geräten weltweit.
Dass die Behebung dieses Problems Kosten in Milliardenhöhe verursachen wird, ist absehbar – der Vergleich mit dem Y2K Problem liegt nahe. Weniger klar ist, wer im Ernstfall für Ausfälle und Schäden haftet. Das Beispiel Alstom zeigt, wie schnell diese Frage konkret wird: Ein Gericht in Frankreich hat im Herbst 2025 nach langjährigem Streit mit der RATP klargestellt, dass der Zughersteller für die Behebung des Problems haftbar gemacht werden kann. Alstom versuchte dabei, die Verantwortung auf den Einsatz von Open Source zu verlagern, mit dem Hinweis, dieser sei auf Wunsch des Kunden erfolgt. Damit wird Open Source zum Sündenbock gemacht, ein Beispiel, das Schule machen könnte.
«La société Alstom Transport fait valoir en deuxième lieu que la RATP, dans les documents contractuels préparatoires, préconisait l’usage de logiciels open source, que la plupart des logiciels open source sont encore à ce jour codés en 32 bits signé et sont donc concernés par l’Echéance d’Horodatage 2038.»
„Alstom Transport macht zweitens geltend, dass die RATP in den vorbereitenden Vertragsunterlagen den Einsatz von Open-Source-Software empfohlen habe, dass die meisten Open-Source-Programme bis heute noch in signed 32-Bit codiert seien und daher vom Zeitstempel-Stichtag 2038 betroffen seien.»
– Tribunal Administratif de Paris N° 1921668, 13. November 2025
Warum steht Open Source bei Y2K38 im Fokus?
Das Jahr-2038-Problem hat seinen Ursprung in der klassischen Unix-Zeit, die ursprünglich oft als 32-Bit-Variable implementiert wurde. Diese Logik wurde über Jahrzehnte in zahlreiche Systeme übernommen. Auch Linux als Unix-ähnliches Betriebssystem trägt dieses Erbe weiter. Gleichzeitig ist Linux heute eines der bekanntesten und am weitesten verbreiteten Open-Source-Projekte überhaupt. Damit rückt Open Source automatisch in den Fokus, wenn über Y2K38 gesprochen wird, nicht weil der Ursprung dort liegt, sondern weil ein großer Teil der heutigen digitalen Infrastruktur darauf aufbaut.
Hinzu kommt: Open-Source-Projekte sind per Definition transparent. Der Quellcode ist offen, Probleme sind nachvollziehbar, der Y2K38-Bug lässt sich analysieren und seine Auswirkungen lassen sich konkret nachvollziehen. Fehler werden öffentlich diskutiert und dokumentiert. Diese Offenheit ist eine Stärke, führt aber auch dazu, dass Open Source leichter angreifbar wirkt als geschlossene Systeme, bei denen viele Probleme im Verborgenen bleiben.
Transparenz von Open Source – Schweigen auf Seiten der Hersteller
Während in Open-Source-Projekten das Jahr-2038-Problem längst offen diskutiert und aktiv angegangen wird, ist die Situation in der Industrie und bei proprietären Systemen deutlich undurchsichtiger. Die französische Journalistin Muriel Valin stieß bei Recherchen zum Y2K38-Bug genau darauf: auf eine Mauer des Schweigens.
«Et c’est à peu près tout. Sur la vingtaine de structures que nous avons contactées (Google, Siemens, EDF, SNCF, ESA, Bosch, Orange…), la majorité n’a pas répondu ou a minima. “Nous ne pouvons malheureusement pas donner suite à votre demande”, nous dit le service de presse de Renault. “Chez Valeo, on connaît le sujet. Le risque est maîtrisé dans le domaine de l’auto car il y a depuis longtemps des standards pour anticiper ce type de problème. Nous n’avons pas d’autres informations à communiquer sur le sujet.”»
«Von den rund zwanzig Organisationen, die wir kontaktierten (Google, Siemens, EDF, SNCF, ESA, Bosch, Orange usw.), reagierte die Mehrheit nicht oder gab nur minimales Feedback.
„Leider können wir Ihre Anfrage nicht beantworten“, teilte uns die Pressestelle von Renault mit.
„Wir bei Valeo sind mit dem Problem vertraut. Im Automobilsektor wird das Risiko beherrscht, da seit Langem Standards existieren, um solche Probleme zu antizipieren. Wir haben dazu keine weiteren Informationen.“ »– Muriel Valin, epsiloon.com, Le bug de l’an 2038, 25. Februar 2026
Der Kontrast könnte kaum größer sein: Während Open Source Probleme sichtbar macht, dokumentiert und öffentlich diskutiert, bleibt bei vielen Herstellern unklar, wie weit die eigenen Systeme tatsächlich vorbereitet sind. Es wäre jedoch naiv anzunehmen, dass die relevanten Probleme bereits flächendeckend gelöst sind. Das Beispiel Alstom zeigt, dass konkrete Risiken bis heute bestehen und im Ernstfall real werden. Weitere aktuelle Fälle, etwa Sicherheitslücken bei WAGO oder Dover Fueling Solutions, unterstreichen, dass das Thema keineswegs abgeschlossen ist. Auch eigene Tests zeigen, wie greifbar das Problem ist: Bei einem einfachen Selbstversuch durch BEOZ Association konnte durch eine gezielte Datumsänderung ein Fernseher zum Absturz gebracht werden.
Wo Open-Source-Projekte den Y2K38-Bug angehen
Es gibt unzählige Open-Source-Projekte, die von engagierten Freiwilligen oder von Unternehmen unterstützten Profis vorangetrieben werden. Gerade beim Jahr-2038-Problem zeigt sich, wie wirkungsvoll ein offener, kollaborativer Ansatz sein kann: Viele der grundlegenden Probleme wurden bereits identifiziert und in zentralen Projekten systematisch angegangen.
Linux-Kernel: Fundament seit 2020 gelegt
Der wichtigste Meilenstein im Umgang mit dem Y2K38-Problem wurde im Linux-Kernel erreicht.
Bereits um 2014 startete Arnd Bergmann (Linaro) die Arbeiten zur Umstellung aller relevanten Zeitstrukturen und Systemaufrufe von 32-Bit auf 64-Bit („time64“). Ziel war es, die klassische time_t-Limitierung zu beseitigen.
Ein entscheidender Durchbruch kam 2020:-
- Linux Kernel 5.6 (März 2020) brachte erstmals eine weitgehend vollständige time64-Unterstützung.
- Linux Kernel 5.10 (Dezember 2020) gilt als erste Version ohne bekannte Y2K38-Probleme auf 32-Bit-Architekturen.
Damit ist die Grundlage geschaffen: Moderne Linux-Kernel sind im Kern Y2K38-sicher.
Allerdings löst das allein das Problem nicht. Die neuen Kernel müssen auch in Distributionen und bestehende Systeme gelangen. Bis Ende 2025 haben die meisten aktiv gepflegten Distributionen nachgezogen. Gleichzeitig existieren jedoch noch über 600 veraltete oder nicht mehr gepflegte Distributionen, die weiterhin betroffen sind.
Das zeigt eine typische Schwäche – aber auch eine Stärke von Open Source:
Ungepflegte Systeme bleiben verwundbar, können aber prinzipiell jederzeit von der Community weitergeführt und korrigiert werden.
openSUSE: Koordinierte Community-Initiative
Dass die Arbeit nach den Kernel-Fixes nicht endet, zeigt die openSUSE-Community sehr deutlich.
Sie hat eine Initiative gestartet, um verbleibende Y2K38-Probleme systematisch zu identifizieren und zu beheben – sowohl in bestehenden Paketen als auch in neuem Code. Dabei geht es nicht nur um offensichtliche Fehler, sondern auch um versteckte Abhängigkeiten und Altlasten in Bibliotheken und Anwendungen.
Ziel ist ein koordinierter, distributionsweiter Ansatz statt einzelner, isolierter Fixes.
Beispiel: https://news.opensuse.org/2026/01/20/os-community-tackling-y2k38-epoch/
Weitere relevante Open-Source-Bausteine
Der Kernel ist nur die Basis. Auch andere zentrale Projekte haben Anpassungen vorgenommen:
- glibc (GNU C Library)
Einführung von 64-Bit-Zeitfunktionen (time64), entscheidend für User-Space-Programme.
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - musl libc
Frühzeitige und saubere Unterstützung für 64-Bit-Zeit auf allen Architekturen.
https://musl.libc.org/time64.html - BusyBox
Anpassungen für Embedded-Systeme, die häufig noch 32-Bit nutzen. - Debian / Ubuntu / Fedora
Distributionen haben aktiv Pakete migriert und Builds auf time64 umgestellt.
Kein 2038 Problem bei kommerziellen Herstellern?
Bei Microsoft ist die Lage noch weniger transparent. Zwar laufen moderne Windows-Systeme auf 64 Bit und basieren nicht auf Unix. Doch scheint es auch hier noch Probleme zu geben. Eigene Tests zeigen, dass selbst auf aktuellen Systemen Programme wie der Windows Media Player bei entsprechenden Datumswerten versagen können.
Aufgrund des weitgehenden Schweigens grosser Hersteller könnte man meinen, das Y2K38-Problem sei längst gelöst. Doch dieser Eindruck täuscht.
Apple und Google haben das Problem nicht wirklich behoben, sondern systematisch aus ihrem Ökosystem verdrängt. Durch den konsequenten Wechsel auf 64-Bit wurden ältere Geräte und Software faktisch ausgesondert. Das ist weniger eine Lösung als eine Form von geplanter Obsoleszenz: Was nicht mehr passt, wird ersetzt.
Y2K38 ist strukturell – wie tief das Problem in der Industrie steckt
Der Fall Alstom ist kein isoliertes Ereignis, sondern ein Hinweis auf ein strukturelles Problem. Nach gesundem Menschenverstand wird das Beispiel der Pariser Züge kaum ein Einzelfall sein. Industrielle Systeme dieser Art werden nicht einmalig entwickelt, sondern über Jahre hinweg weiterverwendet, angepasst und in unterschiedlichen Projekten eingesetzt. Architekturentscheidungen verbreiten sich so über ganze Produktlinien und Generationen hinweg.
Gerade in der Industrie sind Lebenszyklen lang. Steuerungen, Leitsysteme und eingebettete Komponenten bleiben oft 20 bis 30 Jahre oder länger im Einsatz. In dieser Zeit werden sie erweitert, integriert oder nur teilweise modernisiert. Es entstehen gewachsene Systemlandschaften, in denen neue Komponenten auf bestehende Strukturen treffen.
Das Risiko liegt genau in diesen hybriden Systemen. Selbst wenn zentrale Teile aktualisiert wurden, können an anderer Stelle weiterhin alte Zeitformate verwendet werden – etwa in Schnittstellen, Datenformaten oder internen Berechnungen.
Hinzu kommt die grundlegende Verbreitung der Mechanik: Zeitverarbeitung ist eine Basisfunktion, die in nahezu jedem digitalen System vorkommt – von industriellen Steuerungen über Kommunikationssysteme bis hin zu Abrechnung und Überwachung.
Das Jahr-2038-Problem ist deshalb kein einzelner Defekt, sondern ein verteiltes Risiko. Bekannte Fälle sind weniger Ausnahmen als Hinweise darauf, wie tief diese Problematik bereits in bestehende Infrastrukturen eingebettet ist.
Die entscheidende Frage ist nicht, ob weitere Systeme betroffen sind – sondern wie viele.
Bist du sicher, dass dein System Y2K38 übersteht?
Nehmen wir ein relativ komplexes System wie einen Zug, eine Gebäudeleittechnik oder eine industrielle Steuerung. In der Praxis handelt es sich dabei selten um eine saubere Architektur, sondern eher um das, was in der Softwareentwicklung oft als „Big Ball of Mud“ bezeichnet wird: ein über Jahre gewachsenes Geflecht aus Komponenten, Schnittstellen und Abhängigkeiten.
Ein solches System besteht aus eingekauften Modulen, Open-Source-Bausteinen, intern entwickelten Komponenten aus verschiedenen Abteilungen, Eigenentwicklungen und Legacy-Code. Vieles wurde erweitert, angepasst oder integriert – oft ohne vollständige Dokumentation.
Nun kommt die Aufgabe: Herausfinden, ob dieses System vom Jahr-2038-Problem betroffen ist.
Genau hier zeigt sich die eigentliche Schwierigkeit. Es geht nicht nur darum, den Fehler technisch zu verstehen, sondern überhaupt noch nachvollziehen zu können, wo er auftreten könnte. Menschen haben das Unternehmen verlassen, Zulieferer existieren nicht mehr, Support ist ausgelaufen, und alte Entwicklungsumgebungen sind nicht mehr verfügbar. In einem solchen „Big Ball of Mud“ wird jede Analyse zur Detektivarbeit.
Mit Open Source ist man in dieser Situation klar im Vorteil. Der Quellcode bleibt verfügbar, Abhängigkeiten lassen sich nachvollziehen, Implementierungen können geprüft werden, und Probleme sind dokumentiert. Selbst wenn ursprüngliche Entwickler oder Firmen nicht mehr verfügbar sind, bleibt die Möglichkeit bestehen, Systeme weiter zu verstehen und zu korrigieren.
Open Source verhindert keine Fehler. Aber es verhindert, dass Systeme unrettbar undurchsichtig werden.
Und genau das entscheidet im Jahr 2038 darüber, ob ein Problem lösbar ist – oder nicht.
Y2k38 Bug: Die Rechnung bitte!
Hersteller spüren den Druck. Haftungsfragen stehen im Raum, und damit wächst der Anreiz, Probleme möglichst kleinzureden oder gar nicht erst sichtbar werden zu lassen. Gleichzeitig kämpfen Projektleiter im Alltag mit knappen Ressourcen und engen Zeitplänen. Es ist schwer zu rechtfertigen, heute Budget und Kapazität in ein Problem zu investieren, dessen Auswirkungen erst in über einem Jahrzehnt eintreten könnten.
So entsteht eine gefährliche Dynamik: Das Problem ist bekannt, aber es bleibt liegen.
Auf der anderen Seite stehen Open-Source-Communities. Dort werden Probleme früh benannt, öffentlich diskutiert und schrittweise gelöst. Genau deshalb sind viele der zentralen technischen Grundlagen für Y2K38 bereits heute adressiert.
Doch diese Dynamik ist nicht selbstverständlich. Wenn Open Source gleichzeitig als Sündenbock dargestellt wird, stellt sich eine berechtigte Frage: Wird die Community bereit sein, auf den letzten Metern zu helfen? Wird sie alte Systeme pflegen, Fixes zurückportieren und Verantwortung mittragen, wenn sie zuvor für das Problem verantwortlich gemacht wurde?
Am Ende wird die Rechnung gestellt. Die Frage ist nur: an wen?
