Jahr-2038-Problem

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 7. August 2018 um 07:47 Uhr durch Alexander-93 (Diskussion | Beiträge) (→‎Verwandtes Jahr-2036-Problem). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Zur Navigation springen Zur Suche springen
Exemplarische Darstellung des Jahr-2038-Problems

Das Jahr-2038-Problem von EDV-Systemen (Numeronym: Y2K38) könnte zu Ausfällen von Software im Jahr 2038 führen. Dieses Problem ist auf EDV-Systeme beschränkt, die die Unixzeit benutzen und time_t als vorzeichenbehaftete 32-Bit-Ganzzahl definieren.

Hintergrund

Die Unixzeit zählt die seit dem 1. Januar 1970 abgelaufene Zeit in Sekunden.[1] Am Dienstag, den 19. Januar 2038 um 03:14:08 Uhr UTC wird die Anzahl der vergangenen Sekunden die Kapazität einer vorzeichenbehafteten 32-Bit-Ganzzahl (maximal 2.147.483.647, 231−1) überschreiten.[2] Das signifikanteste Bit (MSB) wird laut Konvention dazu verwendet, positive und negative Zahlen zu unterscheiden (Vorzeichen im Zweierkomplement), sodass die Zählung bei einer Überschreitung des Wertes 2.147.483.647 (binär 01111111111111111111111111111111) in den negativen Bereich springt (z. B. −2.147.483.648 binär 10000000000000000000000000000000). Das führt bei einer ungenügend implementierten Konvertierung von Unixtime zu Datum und Uhrzeit ungewollt zu einem Wert, der vor Beginn der POSIX-Epoche (1. Januar 1970) liegt. Dieses Problem wird in der Softwareentwicklung als Zählerüberlauf bezeichnet.

Ohne Gegenmaßnahmen könnten die wirtschaftlichen Auswirkungen mitunter schädlich sein, zumal im Banken- und Versicherungsumfeld Unix-Systeme neben Mainframes zur Standardausstattung gehören. Neben den Unix-Servern arbeiten viele eingebettete Systeme mit Unix-artigen Betriebssystemen, deren Einsatzzeit oft ein Vielfaches von Desktop- und Serversystemen beträgt (z. B. Router und elektronische Messgeräte). 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.

Ein Beispiel für typische Jahr-2038-Fehler sind Transaktionen, deren Gültigkeit vom Zeitstempel des Ergebnisfeldes abgeleitet wird. Ist das Ergebnis nicht jünger als die Ausgangsdaten, so wird weiterhin auf ein gültiges Ergebnis gewartet oder die Transaktion irgendwann automatisch neu angestoßen. Am Stichtag des Jahr-2038-Problems werden allerdings sämtliche Ergebnisse den vermeintlichen Zeitstempel Dezember 1901 tragen, sind also immer älter als die Eingabedaten. Wartende Programme geraten so leicht in Endlosschleifen, was sich für den Endbenutzer in „hängenden“ Anwendungen äußern könnte.

Abhilfe

Schon deutlich vor dem Jahr 2038 wird der Unixzeit-Zähler in den meisten Systemen voraussichtlich als 64-Bit-Zähler implementiert werden; in OpenBSD ist dies bereits erfolgt. Das hängt damit zusammen, dass die unixtypische C-Definition auf den Basistyp „long“ verweist.[3][4][5] Es hat sich bereits heute im Unixumfeld durchgesetzt, dass beim Übergang von 32-Bit- zu 64-Bit-Architekturen ebendieser Basistyp auf 64 Bit wechselt (technisch: Umstellung von ILP32 auf LP64-Modell), so dass Zeitstempel zumindest systemseitig als 64-Bit-time_t geliefert werden. Durch die 64-Bit-Umstellung kann der POSIX-Zeitstempel 292 Milliarden Jahre zuverlässig arbeiten, ohne dass es zu einem Überlauf kommt.

Dennoch reicht eine Umstellung auf neue 64-Bit-Prozessorarchitekturen (AMD64/EM64T, Itanium/IA-64, IBM Power 5, UltraSPARC, PA-RISC, MIPS) hier alleine nicht aus: Sie vereinfacht zwar die systemseitige Anpassung, macht jedoch die Durchforstung und Neu-Übersetzung aller Programme mit starrer 32-Bit-Formatierung nicht überflüssig. Nicht alle Programme sind bereits 64-Bit-tauglich, und es ist leicht möglich, dass vom System gelieferte 64-Bit-Zeitstempel fälschlicherweise als 32-Bit-Werte weiterverarbeitet werden und somit nur die niederwertigen 32 Bit abgefragt werden, welche dann losgelöst wiederum am 19. Januar 2038 den Wert −231 = 13. Dezember 1901 annehmen.

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 eingebetteten Systemen mit Echtzeitanforderungen in dieser Größenordnung. Neuere Zeit-APIs verwenden immer eine größere Genauigkeit und Spannweite als die Unixzeit, beispielsweise Java System.currentTimeMillis (64-Bit-Millisekunden seit 1. Januar 1970) und .NET System.DateTime.Now.Ticks (64-Bit-10tel Mikrosekunden seit 1. Januar 0001). Die datenbankgestützten Transaktionen verwenden oft TIMESTAMP-Werte, die im Datenbankstandard SQL92 mit einer Genauigkeit in Mikrosekunden definiert sind (auch so zugreifbar in ODBC/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 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 7. Februar 2036 um 06:28:16 Uhr UTC läuft der Zähler des in Unix-Kreisen weit verbreiten Zeitsynchronisations-Protokolls NTP (Network Time Protocol) über. In modernen Implementierungen ist dieses Problem zwar behoben (siehe RFC 5905), doch sehr viele Geräte – besonders eingebettete Systeme – arbeiten noch nach dem alten Standard RFC 868. Auch hier ist der Hintergrund, dass die Zeitübermittlung als 32-Bit-Zahl in Sekunden stattfindet, jedoch nicht vorzeichenbehaftet und mit der Startzeit 1. Januar 1900, 00:00:00 UTC. 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.[6][7] Falls ein Client die bisherige Zeit nicht kennt (Kaltstart auf Systemen ohne Hardware-Uhr) und auch keine Prüfungen auf ein Mindest-Datum (z. B. das Datum seiner Kompilierung, oder Datum der NTP-Software) macht, könnte er versuchen, das Datum 1900-01-01 UTC zu übernehmen, welches nicht in Unix time dargestellt werden kann; dann kann die interne Uhr des betroffenen Systems auf „absurde“ Werte springen, was zu einem Totalausfall führen kann.

Siehe auch

Literatur

  • OpenBSD 5.5 mit 64-bittiger Systemzeit. In: c’t 2014, Heft 12, S. 50.

Einzelnachweise

  1. ↑ Seconds Since The Epoch. Abgerufen am 16. Dezember 2010 (englisch).
  2. ↑ https://www.heise.de/ct/artikel/Prozessorgefluester-285204.html
  3. ↑ Linux Standard Base Core Specification 4.0. Abgerufen am 16. Dezember 2010 (englisch).
  4. ↑ man pages section 3: Library Interfaces and Headers. Ehemals im Original (nicht mehr online verfügbar); abgerufen am 16. Dezember 2010 (englisch).@1@2Vorlage:Toter Link/docs.sun.com (Seite nicht mehr abrufbar. Suche in Webarchiven)  Info: Der Link wurde automatisch als defekt markiert. Bitte prüfe den Link gemäß Anleitung und entferne dann diesen Hinweis.
  5. ↑ HP-UX Reference Volume 5 of 5. types(5). Abgerufen am 16. Dezember 2010 (englisch).
  6. ↑ Vgl. englische Wikipedia NTP Timestamps
  7. ↑ NTP Timescale and Leap Seconds. Abgerufen am 30. November 2015 (englisch).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Jahr-2038-Problem&oldid=179794882“