imported>Kreuzschnabel: Eine Aussage ist keine Definition. Auch dann nicht, wenn sie richtig ist, und schon gar nicht, wenn sie mit „könnte“ bewusst spekulativ formuliert ist :)

2026-03-02T08:27:38Z

Eine Aussage ist keine Definition. Auch dann nicht, wenn sie richtig ist, und schon gar nicht, wenn sie mit „könnte“ bewusst spekulativ formuliert ist :)

Neue Seite

{{Zukunft|2038|1}}
Das '''Jahr-2038-Problem''' von [[Informationssystem|EDV-Systemen]] ([[Numeronym]]: '''Y2K38''') entsteht aus einem [[Arithmetischer Überlauf|Überlauf]] der [[Unixzeit]], wenn diese als [[Integer (Datentyp)#Häufige Speicherformen|vorzeichenbehaftete 32-Bit-Ganzzahl]] abgelegt ist. Mögliche Folgen sind Fehlfunktionen und Ausfälle von IT-Systemen durch falsch gelesene Zeitstempel.

[[Datei:Year 2038 problem.gif|mini|300px|Darstellung des Jahr-2038-Problems: 
1.: Zeitdarstellung im [[Dualsystem|Binärsystem]] 
2.: die dazugehörige [[Dezimalsystem|Dezimalzahl]] 
3.: Fehlerhafte Darstellung der Zeit 
4.: Korrekte Zeitangabe]]

== Hintergrund ==
Die [[Unixzeit]] zählt die seit dem 1. Januar 1970 abgelaufene Zeit in Sekunden.<ref>{{Internetquelle |url=http://pubs.opengroup.org/onlinepubs/009695399/xrat/xbd_chap04.html#tag_01_04_14 |titel=Seconds Since The Epoch |sprache=en |abruf=2010-12-16}}</ref> Der dafür auf einem 32-Bit-[[Unix]] der 1970er Jahre genutzte [[Datentyp]] <code>time_t</code> ist als vorzeichenbehaftete 32-Bit-[[Integer (Datentyp)|Ganzzahl]] definiert und weist einen Maximalwert von 2.147.483.647 bzw. 231−1 auf. Auf allen dazu [[Kompatibilität (Technik)|kompatiblen]] Unix- und [[Unixoides System|Unix-artigen]] Systemen der darauffolgenden Jahrzehnte wird am Dienstag, dem 19. Januar 2038 um 03:14:07 Uhr [[Koordinierte Weltzeit|UTC]] die Anzahl der vergangenen Sekunden diese Kapazität überschreiten.<ref>{{Literatur |Autor=c’t |Titel=Prozessorgeflüster: Von Lapithen und Zentauren |Sammelwerk=c’t |Band=2001 |Nummer=19 |Datum=2001-09-10 |ISSN=0724-8679 |Seiten=18 |Online=https://www.heise.de/select/ct/2001/19/ |Abruf=2024-04-10}}</ref> Das signifikanteste Bit ([[Bitwertigkeit#MSb0-Bitnummerierung|MSB]], wie hier im Beispiel meist die linkeste Stelle) wird laut Konvention dazu verwendet, positive und negative Zahlen zu unterscheiden ([[Vorzeichen (Zahl)|Vorzeichen]] im [[Zweierkomplement]]), sodass die Zählung bei einer Überschreitung des Wertes 2.147.483.647 (binär 01111111 11111111 11111111 11111111) in den negativen Bereich springt (z. B. −2.147.483.648 binär 10000000 00000000 00000000 00000000). Das führt bei einer ungenügend implementierten Konvertierung von Unixzeit zu Datum und Uhrzeit ungewollt zur Interpretation des Wertes als 20:45:52 Uhr am Freitag, 13. Dezember 1901 UTC. Dieses Problem wird in der Software-Entwicklung als [[Arithmetischer Überlauf|Zählerüberlauf]] bezeichnet.

Ohne Gegenmaßnahmen könnten die wirtschaftlichen Auswirkungen unter Umständen schädlich sein, zumal teilweise weiterhin 32-Bit-Unix-Systeme im Einsatz sind, die zu UNIX [[Binärschnittstelle|ABI]]-kompatibel blieben (vgl. [[POSIX]]). Anders als bei Anwendungsbereichen wie Unix-Servern und PCs, auf denen der Übergang zu einer [[64-Bit-Architektur]] als abgeschlossen angenommen werden kann, existieren weiterhin viele [[Eingebettetes System|eingebettete Systeme]] mit [[Unixoides System|Unix-artigen]] Betriebssystemen und [[32-Bit-Architektur]], deren Einsatzzeit oft ein Vielfaches von Desktop- und Serversystemen beträgt (z. B. [[Router]], elektronische [[Messgerät]]e, Automobil-Systeme, [[Internet der Dinge|IoT]], [[Fernsehgerät]]e, Geräte in der Anlagensteuerung und Gebäudeüberwachung/-steuerung<ref name="Linux-Magazin_2024-03-05_Debian" />). Zudem wurde bei der Portierung bestehender Software von 32 auf 64 Bits u. U. nicht vollständig überprüft, ob die 64-Bit-Zeitstempel auch korrekt und unbeschnitten weiterverarbeitet werden. Eine zumindest verzögerte, auf Dauer aber notwendige Anpassung bzw. Modernisierung entsprechender Rechnersysteme in Unternehmen und Institutionen in heutiger Zeit könnte die Ausfallwahrscheinlichkeit senken.

== Beispiel ==
Ein Beispiel für Jahr-2038-Fehler ist die Gültigkeitsprüfung per Zeitstempel: Hierzu wird beim Beginn eines Vorganges die aktuelle Zeit gespeichert. Mit dieser kann sichergestellt werden, dass bis zum Abschluss des Vorgangs nicht mehr Zeit verstreicht als vorgegeben (beispielsweise die [[Abmeldung#Computersystem|automatische Abmeldung]] beim [[Onlinebanking]] nach wenigen Minuten zur Missbrauchsvermeidung). Springt innerhalb einer solchen Frist der vom System angegebene Zeitstempel auf das Jahr 1970, so ist die Differenz fortan immer negativ. Erwartet das Programm nun aber eine positive Zahl mit einer Mindestgröße (z. B. 5 Minuten nach Beginn des Vorganges), wartet es vergeblich darauf, dass die Zahl positiv wird – die Zahl bleibt somit immer kleiner als der Zielwert von beispielsweise 5 Minuten. Das kann zu unerwünscht lange offen bleibenden Sicherheitszugängen führen oder auch zu [[Endlosschleife (Programmierung)|Endlosschleifen]], was sich für den Endbenutzer wie ein [[Absturz (Computer)|Nichtreagieren]] des [[Computerprogramm|Programms]] äußern kann.

== Abhilfe ==
Im Unix-Umfeld hat sich beim Übergang von [[32-Bit-Architektur|32-Bit]]- zu [[64-Bit-Architektur]]en durchgesetzt, dass der Basistyp „[[Integer (Datentyp)|long]]“ der [[C (Programmiersprache)|Programmiersprache C]] von 32 Bit auf 64 Bit aufgeweitet wird (technisch: Umstellung von ILP32 auf LP64-Modell, siehe [[Datentypen in C]]). Dieser Datentyp entspricht der traditionellen Definition von <code>time_t</code> als größtem verfügbaren Basistyp, bevor mit C99 und UNIX98 der „long long“ Basistyp standardgemäß eingeführt wurde.<ref>{{Internetquelle |url=https://unix.org/whitepapers/64bit.html |titel=Data Size Neutrality and 64-bit Support |hrsg=The Open Group |sprache=en |abruf=2023-07-04}}</ref> Solche 64-Bit-Systeme sind damit auf einen POSIX-Zeitstempel mit 64-Bit-Sekunden seit 1. Januar 1970 umgestellt, womit sie für 292 Milliarden Jahre zuverlässig arbeiten könnten.

Dennoch reicht eine Umstellung auf neue 64-Bit-Prozessorarchitekturen ([[x64]], [[Itanium-Architektur|Itanium/IA-64]], [[IBM Power#Power5|IBM Power 5]], [[SPARC-Architektur|UltraSPARC]], [[PA-RISC]], [[MIPS-Architektur|MIPS]], [[ARMv8]]) hier alleine nicht aus: Sie vereinfacht zwar die systemseitige Anpassung, das macht jedoch die Durchforstung und [[Kompilieren|Neuübersetzung]] aller Programme mit starrer 32-Bit-Formatierung nicht überflüssig. Die meisten Programme sind inzwischen für 64-Bit-Architekturen angepasst worden, allerdings ist es dennoch leicht möglich, dass an verschiedenen Stellen im Programm der vom System gelieferte 64-Bit-Zeitstempel fälschlicherweise als 32-Bit-Wert weiterverarbeitet wird und somit nur die niederwertigen 32 Bits abgefragt werden, welche dann losgelöst wiederum am 19. Januar 2038 den Wert −231 = 13. Dezember 1901 annehmen. Auch bleiben weiterhin 32-Bit-Programme im Einsatz, z. B. auf 64-Bit-[[Multilib]]-Systemen, die eventuell wegen bestehender [[Binärschnittstelle|ABI]]-Kompatibilität nicht angepasst werden können. In beiden Fällen, also für 32-Bit-Programme (oder zwar inzwischen angepassten 64-Bit-fähigen Programmen, die aber für 32-Bit-Systeme übersetzt wurden) sowie für nicht vollständig überarbeitete und überprüfte 64-Programme, sind u. U. weiterhin 32-Bit-Zeitstempel in Verwendung.

Um 32-Bit-Systeme bzw. -Programme, die weiterhin in Verwendung sind, auch über das Jahr 2038 hinaus benutzbar zu machen, haben einige Betriebssysteme auch für 32-Bit-Architekturen die Definition von <code>time_t</code> auf 64-Bit umgestellt. Dies ist etwa bei [[NetBSD]] ab Version 6.0 von 2012, bei [[OpenBSD]] ab Version 5.5 von 2014 und beim [[Linux (Kernel)|Linux-Kernel]] ab Version 5.6 von 2020 der Fall.<ref>{{Internetquelle |url=https://www.netbsd.org/releases/formal-6/NetBSD-6.0.html |titel=Announcing NetBSD 6.0 |datum=2012-10-17 |sprache=en |abruf=2016-01-18}}</ref><ref>{{Internetquelle |url=http://www.openbsd.org/plus55.html |titel=OpenBSD 5.5 released (May 1, 2014) |werk=openbsd.org |datum=2014-05-01 |sprache=en |abruf=2016-01-18}}</ref><ref>{{Internetquelle |autor=Arnd Bergmann |url=https://lkml.org/lkml/2020/1/29/355?anz=web |titel=[GIT PULL&#93 y2038: core, driver and file system changes |werk=LKML.org |sprache=en |abruf=2020-01-30}}</ref> Zwar hatte man auf der Applikationsebene schon vorher die Verwendung von 64-Bit Alternativen vorgeschlagen,<ref>{{Internetquelle |url=http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic.html#AEN7164 |titel=Linux Standard Base Core Specification 4.0 |sprache=en |abruf=2010-12-16}}</ref><ref>{{Internetquelle |url=http://docs.sun.com/app/docs/doc/816-5173/types.h-3head |titel=man pages section 3: Library Interfaces and Headers |sprache=en |offline=2018-04-16 |abruf=2010-12-16}}</ref><ref>{{Internetquelle |url=http://docs.hp.com/en/B2355-90684/types.5.html |titel=types(5) |werk=HP-UX Reference Volume 5 of 5 |sprache=en |abruf=2010-12-16}}</ref> allerdings verblieb meist die alte [[Binärschnittstelle]] (ABI) erhalten, da sonst eine komplette Neuübersetzung aller 32-Bit-Programme notwendig gewesen wäre. Für einzelne Programme hatte die [[GNU-C-Bibliothek]], eine der verbreiteten [[C-Standard-Bibliothek]]en, für die Umstellung entsprechend bereits eine <code>time64_t</code>-Definition eingeführt.<ref>{{Internetquelle |url=https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html |titel=64-bit time symbol handling in the GNU C Library |werk=GNU.org |sprache=en |abruf=2023-07-04}}</ref> Eine ähnliche Definition <code>__time64_t</code> wird im Windows-Umfeld verwendet, und mit Visual C++ 2005 wurde der Default auf <code>time64</code> geändert.<ref>{{Internetquelle |url=https://docs.microsoft.com/de-de/cpp/c-runtime-library/reference/time-time32-time64 |titel=time, _time32, _time64 |werk=docs.Microsoft |sprache=en |abruf=2023-07-04}}</ref> Weil die verbreiteten [[x86-Architektur|x86]]-Distributionen bereits um das Jahr 2020 für 32-Bit „[[IA-32]]“ (teils auch mit „[[i386]]“ bezeichnet) nicht fortgeführt und vollständig von deren 64-Bit-Varianten ([[x64]], mit den Alternativbezeichnungen „amd64“ bzw. „x86-64“) beerbt wurden, haben die meisten [[Linux-Distribution]]en das Jahr-2038-Problem bis zuletzt nie vollständig gelöst, verblieben dadurch jedoch ABI-kompatibel. Die noch bestehenden 32-Bit-Distributionen haben um 2020 begonnen, alle 32-Bit-Zeitstempel in bestehender Software durchgehend zu 64-Bit-Datentypen zu überführen. So verkündete etwa [[Debian|Debian GNU/Linux]] erst 2024, alle bestehenden 32-Bit-[[Portierung (Software)|Ports]] vollständig umzustellen (z. B. [[ARMv7]]), allerdings mit Ausnahme der 32-Bit-x86-Architektur (i386 und i386-hurd).<ref name="Linux-Magazin_2024-03-05_Debian">{{Internetquelle |autor=Ulrich Bantle |url=https://www.linux-magazin.de/news/64-bit-time-debian-geht-jahr-2038-problem-an/ |titel=64-Bit-Time: Debian geht Jahr-2038-Problem an |werk=[[Linux-Magazin]] Online |hrsg=[[Computec Media]] |datum=2024-03-05 |abruf=2024-04-07}}</ref> Gerade auf der x86-Architektur gibt es seit der Umstellung auf 64 Bit größere Veränderungen, wie beispielsweise doppelt so viele [[Register (Prozessor)|Register]], die auch 32-Bit-Anwendungen zugutekommen können – allerdings nur im 64-Bit-Betriebsmodus von amd64 bzw. x64. Weil dieser aber nicht vollständig mit i386 bzw. IA-32 kompatibel ist, wurde unter Linux mit „[[x32 (ABI)|x32]]“ eine neue Binärschnittstelle (ABI) geschaffen, die – als Neuentwicklung – nicht zum bestehenden 32-Bit-x86-ABI (i386) kompatibel sein musste. Weil x32 im nativen 64-Bit-Modus läuft, verbleiben auch einige Datentypen 64-bittig, darunter <code>time_t</code>,<ref>{{Internetquelle |autor=Jonathan Corbet |url=https://lwn.net/Articles/456731/ |titel=The x32 system call ABI |werk=LWN.net |datum=2011-08-29 |abruf=2024-04-11}}</ref> sodass 32-Bit-Programme auf 64-Bit-„x32“-Systemen genau gleich wie unter x64 betroffen oder, bei korrekter Anpassung bestehender Software, nicht betroffen sind.

Eine andere Abhilfe ist die Umstellung der Programme vom Unixzeit-Zähler auf eine neue [[Zeitbasis]]; schon verbreitet ist etwa die Zählung von Millisekunden oder Mikrosekunden mit 64-Bit-Zählern (die nicht notwendigerweise eine 64-Bit-Architektur erfordern), insbesondere in [[Eingebettetes System|eingebetteten Systemen]] mit Echtzeitanforderungen in dieser Größenordnung. Neuere Zeit-[[Programmierschnittstelle|APIs]] verwenden immer eine größere Genauigkeit und Spannweite als die Unixzeit, beispielsweise [[Java (Programmiersprache)|Java]] <code>System.currentTimeMillis</code> (64-Bit-Millisekunden seit 1. Januar 1970; ausreichend für 292 Millionen Jahre) und [[.Net-Framework|.NET]] <code>System.DateTime.Now.Ticks</code> (64-Bit-10tel Mikrosekunden seit 1. Januar 0001; ausreichend für 29227 Jahre). Die datenbankgestützten Transaktionen verwenden oft <code>TIMESTAMP</code>-Werte, die im Datenbankstandard [[SQL]]92 mit einer Genauigkeit in Mikrosekunden definiert sind (auch so zugreifbar in [[Open Database Connectivity|ODBC]]/[[Java Database Connectivity|JDBC]]) und deren Repräsentation in Datenbanken meist als Abstand zum Tageszähler (SQL DATE) erfolgt, wobei der Tageszähler auch in 32 Bit eine größere Spannweite besitzt (die zugrunde liegende Epoche des Tageszählers ist jedoch sehr verschieden). Sofern diese Datentypen für Zeitstempel im Programm durchgängig weiterverwendet werden, heben sich die Beschränkungen des Unixzeit-Zählers auf.

Eine weitere Abhilfemöglichkeit ist die Speicherung des Zeitstempels als [[Zeichenkette]], so wie es gemäß [[ISO 8601]] vorgesehen ist, als YYYYMMDDhhmmss-Zeitstempel, z. B. „20140823142216“. Diese bleiben mindestens bis zum 31. Dezember 9999 23:59:59 Uhr von Jahr-Überlauf-Problemen verschont, sofern nicht die internen Operationen (z. B. zur Berechnung der Differenz zwischen zwei Zeitstempeln) diese in ein problematisches Binärformat umwandeln.

== Verwandtes Jahr-2036-Problem ==
Eng verwandt zum ''Jahr-2038-Problem'' ist das Jahr ''2036'' (Numeronym: ''Y2K36'').
Am Donnerstag, 7. Februar 2036 um 06:28:16 Uhr UTC läuft der Zähler des ursprünglich für UNIX entwickelten Zeitsynchronisations-Protokolls NTP ([[Network Time Protocol]]) über. In modernen Implementierungen ist dieses Problem zwar behoben (siehe <nowiki>RFC 5905</nowiki><ref>{{RFC-Internet |RFC=5905 |Titel=Network Time Protocol Version 4: Protocol and Algorithms Specification |Datum=2010-06}}</ref>), doch sehr viele Geräte – besonders [[eingebettete Systeme]] – arbeiten noch nach dem alten Standard <nowiki>RFC 868</nowiki>.<ref>{{RFC-Internet |RFC=868 |Titel=Time Protocol |Datum=1983-05}}</ref>

Auch hier ist der Hintergrund, dass die Zeitübermittlung als 32-Bit-Zahl in Sekunden stattfindet, jedoch mit der Startzeit 1. Januar 1900, 00:00:00 Uhr UTC und nicht vorzeichenbehaftet. Bei sehr ordentlicher Implementierung der Systeme kommt es sogar hier zu keinem (größeren) Problem während der Berechnung, da die Zeitsynchronisation nach einer Differenz-Methode arbeiten sollte.<ref>Vgl. englische Wikipedia [[:en:Year 2038 problem#NTP timestamps|NTP Timestamps]]</ref><ref>{{Internetquelle |url=http://doc.ntp.org/4.1.2/leap.htm |titel=NTP Timescale and Leap Seconds |sprache=en |abruf=2015-11-30}}</ref>

Allerdings können ungültige Werte – implementierungsabhängig – auch dadurch auftreten, dass sowohl im NTP- als auch UNIX-Format gearbeitet wird: Dies betrifft insbesondere die wachsende Zahl [[Eingebettetes System|eingebetteter Systeme]] im Rahmen des [[Internet der Dinge|Internet of Things]], wo zwar mangels batteriegestützter [[Echtzeituhr]] die Ermittlung der Systemzeit nach jedem Start zunächst im NTP-Format über [[Zeitserver]] erfolgen muss, diese in der Folge dann aber zur weiteren Repräsentation in die übliche Unixzeit konvertiert wird (durch Abzug der Zeitdifferenz). Wird hier die Zeit nach (nicht selten) fehlgeschlagenen Verbindungsversuchen mit 0 angegeben und dementsprechend mit <code style="white-space:nowrap">1900-01-01 00:00:00 UTC</code> (in Unixzeit nur als negativer Wert darstellbar), würden nicht abgesicherte Konvertierungen zum UNIX-Format zu einem ungültigen und (wenn vorzeichenbehaftet) zudem negativen Wert führen, mit vergleichbaren Auswirkungen auf das System und sein Verhalten.

== Siehe auch ==
* Der Kontakt zur Raumsonde [[Deep Impact (Sonde)|Deep Impact]] brach am 8. August 2013 ab. Analysen verweisen im Zusammenhang mit dem Zeitpunkt auf den Überlauf eines 32-Bit-unsigned-Zeitzählers, der in 100-ms-Schritten seit dem 1. Januar 2000 rechnete.<ref>{{Internetquelle |url=https://llis.nasa.gov/lesson/10701 |titel=Llis (NASA Lessons Learned system) |hrsg=[[NASA]] |abruf=2023-04-12}}</ref>
* [[Jahr-2000-Problem]]
* [[Jahr-2010-Problem]]
* [[Jahr-2022-Problem]]
* [[Jahr-2106-Problem]]

== Literatur ==
* ''OpenBSD 5.5 mit 64-bittiger Systemzeit''. In: ''[[c’t]]'', 2014, Heft 12, S. 50.

== Einzelnachweise ==
<references />

[[Kategorie:POSIX]]
[[Kategorie:Programmfehler| ]]
[[Kategorie:2038]]

Jahr-2038-Problem - Versionsgeschichte

imported>Kreuzschnabel: Eine Aussage ist keine Definition. Auch dann nicht, wenn sie richtig ist, und schon gar nicht, wenn sie mit „könnte“ bewusst spekulativ formuliert ist :)