Vom Millennium-Bug oder dem Jahr-2000-Problem haben sicherlich viele schon einmal gehört; das Jahr-2038-Problem dagegen ist aber vermutlich nicht ganz so verbreitet. Beide Probleme haben (bzw. hatten) etwas mit der Zeitdarstellung im Computer zu tun, wobei allerdings jeweils ein anderer Mechanismus Ursache des Problems ist/war. Schauen wir uns daher einmal beide Probleme im Detail an. Die Inspiration kam übrigens durch ein Numberphile-Video auf Youtube (ich kann den Kanal sehr empfehlen), welches am Ende des Artikels eingebettet ist.
Das Jahr-2000-Problem
Fangen wir mit dem Jahr-2000-Problem an, insbesondere auch, da das glücklicherweise mittlerweile erledigt ist. Der Kern des Jahr-2000-Problems – ich möchte weniger von einem Bug reden, da das Problem zusammen mit den Bedingungen für das Auftreten lange im Voraus bekannt war – war die Darstellung von Jahreszahlen in den früheren Jahren der Softwareentwicklung.
Prinzipiell lassen sich Zahlen im Computer auf 2 Arten darstellen: in ihrer binären Form (die 1310 entspricht etwa der 11012 – wir erinnern uns), oder in der Darstellung der einzelnen Positionen der Zahl durch ihre Ziffern (im Falle der 13 also “1” und “3”). Der Vorteil der Binärdarstellung ist, dass Zahlen unabhängig von ihrer Größe zur Speicherung eine feste, geringe Menge an Speicherplatz – in der Regel 1, 4 oder 8 Byte (8, 32 bzw. 64 Bit) – benötigen. Der Nachteil dagegen ist, dass in Binärform gespeicherte Zahlen nicht einfach so auf dem Bildschirm dargestellt werden können. Zur Darstellung von Zeichen müssen diese im ASCII-Format (wir erinnern uns) – oder einem erweiterten Format – abgelegt werden; hierbei wird jedes Zeichen (also jeder Buchstabe, jede Zahl, jedes Satzzeichen usw.) durch eine 1-Byte-Zahl (oder bei erweiterten Formaten entsprechend größere Zahlen) codiert. Der Buchstabe ‘A’ entspricht hierbei etwa der Zahl 65, die Ziffer ‘1’ der 49 und so weiter. Zur Darstellung der 13 werden also 2 Byte benötigt – eines für jede Ziffer.
Das eigentliche Problem dieser Art der Darstellung ist, dass oft zur Darstellung von Jahreszahlen lediglich die letzten beiden Ziffern, also etwa ’85’, verwendet wurden (Speicher war teuer damals, und man musste so viel davon sparen, wie möglich). Solange klar war, dass die ausgelassenen Ziffern für ’19’ (also das 20. Jahrhundert) standen, war alles in Ordnung. Zum Jahrtausendwechsel ergab sich aber ein Problem: die letzten beiden Ziffern der gespeicherten Jahreszahlen würden zurück auf ’00’ wechseln, ohne dass eine Information über das neue Jahrtausend (’20’ am Anfang der Zahl) in der gespeicherten Zahl enthalten wäre.
Die Folgen wären etwa gewesen, dass Berechnungen* falsch durchgeführt worden wären (00 – 85 ist ja doch etwas anderes als 2000 – 1985) oder dass Datensätze eine falsche Sortierung bekommen hätten (z.B. die ’00’er-Datensätze nach oben und die ’85’er-Sätze nach hinten bei einer Sortierung nach kleinstem Jahr); eine weitere Folge wäre gewesen, dass Datumsangaben das falsche Jahrtausend enthalten hätten, etwa ‘1900’ statt ‘2000’, da die ’19’ fest verdrahtet war und nur die letzten beiden Ziffern dynamisch gespeichert wurden.
*Mit Zahlen in der Ziffernschreibweise lässt sich natürlich nicht gut rechnen; hier ist eine vorherige Rückwandlung in eine binäre Darstellung nötig. Das Problem bleibt dabei aber natürlich bestehen, da ja keine Information über das Jahrtausend mit abgespeichert wurde.
Nun kann man sich natürlich fragen, wie es überhaupt zu diesem Problem kommen konnte – immerhin war lang genug bekannt, dass das Jahrtausend irgendwann endet und neue Ziffern für die Jahresdarstellung nötig wurden. Zudem war Speicherplatz gegen Ende des Jahrtausend auch nicht mehr so teuer, dass derart knausrig mit ihm umgegangen hätte werden müssen, wobei das nur bedingt stimmt – sogenannte eingebettete Systeme (englisch ’embedded systems’), also sehr spezialisierte, kleine Rechner, verfügen auch heutzutage über sehr wenig Speicher, dessen Nutzung genau geplant werden möchte. Viel wichtiger ist aber, dass zur Jahrtausendwende noch unglaublich viele unglaublich alte Computersysteme liefen; bei der Erstellung dieser Systeme hatte niemand damit gerechnet, dass sie so lange laufen würden, oder dass immer neue Systeme auf Basis der bestehenden entwickelt werden würden. Das Problem war also schlicht hausgemacht: das Problem wurde anfangs nicht berücksichtigt, weil niemand daran glaubte, dass es zum Problem werden würde. Da aber viele den Ausspruch “never change a running system” sehr wörtlich nehmen, gab war zur Jahrtausendwende (und auch heute noch!) viel alte Software im Einsatz, die mit der Jahrtausendwende nicht umgehen konnte.
Die Lösung des Problems bestand am Ende daraus, alle Systeme zu identifizieren, die ein derartiges Problem zur Jahrtausendwende hätten haben können, und sie entsprechend anzupassen, etwa durch Anpassung der Software oder den Ersatz durch neue Programme. Das Anpassend oder Ersetzen der Software war natürlich schon aufwändig und teuer genug; als ebenso großes Problem hat sich aber auch der Umstand erwiesen, dass viele Betreiber von Computersystemen überhaupt nicht mehr im Detail wussten, wo sie überall Geräte im Einsatz hatten, die Jahreszahlen im entsprechenden Format speicherten. Zur Jahrtausendwende wurden zwar die meisten dieser Systeme identifiziert und korrigiert, einige wenige (glücklicherweise minder schwere) Fälle von meist falschen Datumsdarstellungen traten aber trotzdem auf. Mit geschätzten Kosten zwischen 300 und 600 Milliarden Dollar1 zur Behebung bzw. Vermeidung war das Jahr-2000-Problem definitiv keine Lappalie, führte aber glücklicherweise auch nicht zu den den prophezeiten Katastrophenszenarien.
Jahr-2038-Problem
Im Jahr 2038 – konkret am 19. Januar 2038, 03:14:08 Uhr – wird uns ein neues, wieder mit einer Datumsdarstellung verbundenes Problem ereilen. Diesmal wird das Problem zwar weniger “hausgemacht” als vielmehr technisch bedingt sein, die Konsequenzen könnten aber um einiges dramatischer als beim Jahr-2000-Problem werden, wenn sich nicht entsprechend darauf vorbereitet wird. Aber im Detail.
Jeder Computer besitzt Viele Betriebssysteme, insbesondere die Unix-basierten, besitzen intern einen kleinen Zähler, welcher die vergangenen Sekunden seit dem 1.1.1970 zählt und zur Bestimmung des aktuellen Datums und der aktuellen Uhrzeit verwendet wird. Dieser Zähler ist normalerweise als vorzeichenbehaftete 32-Bit-Zahl implementiert (wir erinnern uns), das heißt, dass 31 Bit zur Codierung der Zahl zur Verfügung stehen und das 32. (vorderste) Bit speichert, ob wir es mit einer positiven oder negativen Zahl zu tun haben. Der 1.1.1970, 0:00:00 Uhr entspricht der 0000 0000 0000 0000 0000 0000 0000 00002 – eine Zahl mit 32 Nullen. Seit diesem Datum wird dieser Zähler unablässig erhöht, jeweils um 1 in jeder Sekunde.
Wie wir aber wissen, sind Bitketten im Computer endlich – sie können nur bis zu einem bestimmten Wert zählen. Danach sind sie “voll” und es findet ein sogenannter Überlauf statt (ja, das heißt wirklich so). Ein Überlauf findet immer dann statt, wenn zu einer Zahl im Register des Prozessors eine weitere addiert wird, so dass das Ergebnis eine größere Zahl ist, als sie das Register überhaupt fassen könnte. Durch die Arbeitsweise der Rechenwerke von Computern führt ein Überlauf dazu, dass man, wenn man über die größtmögliche darzustellende Zahl “hinausschießt”, im Bereich der kleinstmöglich darzustellenden Zahl landet. Die größte ganze Zahl, die sich mit 32 Bit darstellen lässt, ist die 2.147.483.647. Addiert man im Computer 1 zu ihr, landet man bei der -2.147.483.648, der kleinstmöglich darzustellenden ganzen Zahl.
Und genau das wird am 19. Januar 2038 um 03:14:08 Uhr passieren; dann erreicht der Zähler für die Sekunden seinen maximalen Wert – 0111 1111 1111 1111 1111 1111 1111 1111 11112 (das vorderste Bit ist das Vorzeichenbit) – und er wird umschlagen auf die nächste Zahl, die 1000 0000 0000 0000 0000 0000 0000 00002 (die kleinstmöglich darstellbare ganze Zahl mit 32 Bit). Rechnet man diese Zahl in ein Datum um, so ergibt sich der 13. Dezember 1901, 20:45:52 Uhr. Wer sich jetzt übrigens fragt, warum der Sekundenzähler als vorzeichenbehaftete Zahl implementiert wurde, wo doch das Vorzeichen dazu führt, dass bereits 2038 die höchstmögliche Zahl erreicht wird: das wurde festgelegt, um auch Zeiten vor dem 1.1.1970 über den Sekundenzähler darstellen zu können, was sonst ja nicht möglich gewesen wäre.
Das Jahr-2038-Problem könnte kritischere Auswirkungen als das Jahr-2000-Problem haben, da bei letzterem lediglich Systeme betroffen waren, die Jahreszahlen in dem beschriebenen 2-Ziffern-Format abgespeichert haben. Der Überlauf des Sekundenzählers wirkt sich dagegen auf alle Systeme aus, die in irgendeiner Weise auf ein vom Computer geliefertes Datum oder eine Zeit zurückgreifen, und das sind ziemlich viele.
Eine relativ einfache Möglichkeit zur Lösung besteht darin, statt der 32 Bit für den Zähler einen 64-Bit-Wert zu benutzen – der würde erst irgendwann in 292 Milliarden Jahren überlaufen, was nun wirklich in etwas weiterer Zukunft liegt. Schaut man sich die aktuellen Entwicklungen zumindest im Endnutzer-Bereich an, werden bis 2038 auch die meisten, wenn nicht alle Systeme auf 64 Bit umgestellt haben. Leider gilt das aber wohl nur für den Endnutzer-Bereich (wenn überhaupt); in den Betrieben werden wohl getreu der “never change a running system”-Doktrin auch 2038 noch etliche Systeme mit einem 32-Bit-Zähler in Betrieb sein, welcher dann überlaufen würde und zu potentiellen Problemen führt. Wie beim Jahr-2000-Problem muss also auch 2038 eine ausgedehnte Suche nach noch laufenden, alten Rechnersystemen stattfinden und es müssen diese durch 64-Bit-Systeme (oder was auch immer 2038 aktuell ist) ersetzt werden. Leider reicht übrigens das Ersetzen der Hardware durch 64-bit-fähige Hardware nicht unbedingt; viele Programme sind derart programmiert, dass sie nur in ihrer 32-Bit-Variante funktionieren – diese müssen dann entsprechend auch umgeschrieben werden, was wohl ähnlich kostspielig wird wie das Jahr-2000-Problem. Immerhin ist das Problem aber bereits heute bekannt und es kann bereits langfristig darauf hingearbeitet werden, die potentiell fehlerhaften Systeme bis zum Jahr 2038 sämtlich zu ersetzen. Ich bin dennoch gespannt (wenn man es so nennen darf), was alles dabei schiefgehen wird und wo überall am 19. Januar und den Folgetagen noch alte, längst vergessene Rechner auftauchen, die seit Jahrzehnten in staubigen Kammern vor sich hin rechneten.
Und zum Abschluss noch das angekündigte Numberphile-Video:
Kommentare (24)