Jahr-2000-Problem

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Millennium-Bug auf einer Anzeigetafel in Nantes, aufgenommen am 3. Januar 2000

Das Jahr-2000-Problem, auch als Millennium-Bug oder Y2K-Bug (von englisch Year 2 Kilo = ‚Jahr 2000‘) bezeichnet, ist ein Computer­problem, das im Wesentlichen durch die Behandlung von Jahreszahlen als zweistellige Angabe innerhalb von Computersystemen entstanden ist.

Ursachen[Bearbeiten]

In den 1960er und 1970er Jahren war Speicherplatz knapp und teuer. Zum Beispiel konnten Lochkarten nur 80 Stellen speichern, Computer hatten Arbeitsspeicher mit z. B. 64 Kilobyte Größe. Programmierer sparten daher so viel wie möglich an Speicherbedarf ein. Häufig wurden deshalb zur Speicherung und Verarbeitung von Jahreszahlen (in Dezimaldarstellung) nur die letzten beiden Ziffern (Jahr und Jahrzehnt, z. B. im Format ‚TTMMJJ‘ o. Ä.) benutzt, so unter anderem von der Computerpionierin Grace Hopper bei der Entwicklung von COBOL. Das Problem betraf Betriebssysteme, Anwenderprogramme und Datenbestände. Die ersten beiden Ziffern (die das Jahrhundert nennen) wurden nicht berücksichtigt, und man bedachte nicht, dass bzw. ob die Programme über das laufende Jahrhundert hinaus in dieser Weise benutzt würden. Viele Programme (und auch die dazugehörenden Datenbestände) wurden jedoch im Laufe der Jahre immer wieder auf vorangegangenen Versionen aufbauend erweitert, ohne dass dieser ‚bekannte Mangel‘ korrigiert worden wäre. Je näher die Jahrhundertwende kam, desto deutlicher wurde, dass diese Programme die Jahreszahl 00 (und folgende) in vielen Fällen nicht korrekt verarbeiten können.

Nicht direkt damit zusammenhängend, aber nötigenfalls oft gleichzeitig behoben oder kontrolliert wurde eine manchmal unbeachtete Schaltjahr-Regelung des Gregorianischen Kalenders. Nach dieser sind runde Jahrhunderte keine Schaltjahre, außer sie sind durch 400 ganzzahlig teilbar, was nach 1600 erst 2000 wieder der Fall war.

Folgen / Probleme[Bearbeiten]

Die Folgen dieser Fehler wären ohne Korrekturen zum Beispiel falsche Sortierungen gewesen: Daten für (20)00 ganz vorne, ..., (19)98, (19)99 ganz hinten. Vor allem die falsche Berechnung der Zeitdauer (als Differenz zwischen zwei Zeitangaben) hätte zu gravierenden Fehlern in zahlreichen Funktionen geführt. Beispiele: Altersberechnung mit '-40 Jahre' (= Jahr_heute (00 ...) minus Geburtsjahr (40)); Zahlungsrückstand wird nicht erkannt (Datum heute minus Datum der Zahlungsfälligkeit ergibt negative Tage-Anzahl, Mahnungen erst ab Rückstand 30 Tage und mehr, somit 'keine Mahnung'); Sollzinsen für Sparguthaben oder Zinsgutschrift für Kreditzinsen (wegen negativer Tageanzahl in der Zinsformel) u. v. a.

Weiterhin war es weit verbreitete Praxis, nicht vorhandene oder ungültige Dateninhalte mit der Zahl bzw. Ziffernkombination 00 („Nichts“) darzustellen und zu identifizieren – was mit dem Eintreten des Jahres 2000 dann zu Fehlinterpretationen geführt hätte, ggf. sogar zur Nichtverarbeitung ganzer, vermeintlich ungültiger Datensätze. Im Weiteren gäbe es fehlerhafte Erzeugung von Texten (typisches Beispiel hierfür wäre eine Datierung mit der Jahreszahl „1901“ oder „19101“ für das Jahr 2001).

Bei damals älteren PCs kam hinzu, dass die interne Echtzeituhr nicht automatisch das Jahrhundert umschalten konnte, was weder vom BIOS noch von MS-DOS oder Windows 98 automatisch korrigiert wurde. Speziell EDV-gesteuerte Hardwarekomponenten (sog. eingebettete Systeme, engl. embedded systems, z. B. in Alarmanlagen, Videorecordern, Werkzeugmaschinen ...) konnten Probleme darstellen, da hier der Anwender nicht einfach die Software umprogrammieren konnte, sondern dies vom Hersteller (wenn noch vorhanden) erledigen lassen oder sogar die Hardware austauschen musste.

Da es zur Umgehung des Jahr-2000-Problems verschiedene Strategien gab (z. B. Jahr > 50 gilt als 19xx, sonst als 20xx bei weniger langfristigen Zeitdauern; Datenfelder auf vierstellige Jahresangaben oder andere Datumsformate umstellen), mussten die Anwender jeweils exakt planen, in welchen Zusammenhängen welche dieser Strategien anzuwenden war. Da es viele Programme gab, die viele Datenbestände verarbeiteten, musste sichergestellt werden, dass geänderte Programme immer auch entsprechend geänderte Datenbestände voraussetzten. Schwierigkeiten ergaben sich in diesem Zusammenhang für historische Datenbestände: Hier musste entschieden werden, ob diese ebenfalls anzupassen sind oder ob sie noch durch alte (ungeänderte) Programmversionen verarbeitbar sein mussten.

Neben anderen Herausforderungen standen Unternehmen zum Teil vor der Situation, nicht zu wissen, welche Programme und welche Geräte überhaupt Datumsangaben verarbeiten bzw. dann auch Jahr-2000-fähig sind. Dies konnte zu umfangreichen Erhebungs- und Testmaßnahmen führen, die in der Regel deutlich mehr Aufwand verursachten als das Korrigieren fehlerbehafteter Software. Trotzdem mussten die festgelegten Termine absolut sicher eingehalten werden, denn der „1. Januar 2000“ war nicht verschiebbar und viele Anwendungen (die in die Zukunft rechnenden) mussten schon zu früheren Terminen „Y2K-ready“ sein.

Geschichte[Bearbeiten]

Aufgrund dieser Probleme wurden im Vorfeld des Jahreswechsels 1999/2000 Katastrophenszenarien vorhergesagt, dass durch diesen Fehler Computerabstürze in großem Maß erfolgen würden. Inwiefern die Y2K-Problematik von wirklicher Relevanz sein würde, war Ende der 1990er Jahre kaum realistisch zu beurteilen.

Es gab Stimmen in den Medien, die Szenarien apokalyptischen Ausmaßes mit weltweiten Computerzusammenbrüchen prognostizierten. Betroffen sein sollten demnach besonders sicherheitsrelevante Bereiche, die auf Computer angewiesen sind (Banken, Industrie oder auch Kraftwerke, im extremsten Fall der Vorhersagen sogar Atomwaffen), durch das Problem fehlgeschaltet oder gar lahmgelegt würden. Als Folgen wurden vom Verkehrschaos über einen Börsencrash und eine Weltwirtschaftskrise bis zur Fehlauslösung nuklearer Waffensysteme viele Szenarien angeführt – selbst Flugzeugabstürze, obwohl Zeitfehler zu diesem Zeitpunkt längst Teil der Zertifizierungsprozeduren für sicherheitskritische Software waren.

Sorgfältige Analysen von Fachleuten wiesen durchaus auf reale Gefahren hin, vor allem für Wirtschaftsunternehmen.

In praktisch allen großen Unternehmen wurde eine genaue Untersuchung der Computersysteme mithilfe von Diagnoseverfahren angeordnet, um die befürchteten Folgen so gering wie möglich zu halten. Auch wurden Warnaufkleber für jene Geräte verteilt, die bis Ende 1999 systematisch aus dem Betrieb genommen wurden.

Die Software-Industrie reagierte mit einer Überprüfung ihrer Produkte und Herausgabe von Warnlisten, bei welchen Programmen Fehlfunktionen zu befürchten seien. Diese wurden mit Testroutinen für die Hardware (vor allem die Systemuhren) kombiniert.

Privatanwender fanden im Internet Listen mit gefährdeter Hard- und Software.

Während einige Medien noch bis zum kritischen Jahreswechsel 1999/2000 besorgte Berichte verbreitet hatten, stellte sich Anfang 2000 aber heraus, dass die vorsorglichen Maßnahmen im Großen und Ganzen ausreichend gewesen waren: Weltweit wurden in vielen Projekten Programme und Datenbestände (vor allem auf Großrechnern) „saniert“, um den „Y2K-bug“ zu vermeiden. Dennoch hatten viele Banken in der Silvesternacht einfach ihre Geldautomaten abgestellt, um Fehler zu vermeiden.

Aufgetretene gemeldete Probleme[Bearbeiten]

Keines der bekanntgewordenen Jahr-2000-Probleme hatte eine große Auswirkung. Sie traten auch in Ländern wie Italien, die nur wenig in die Behebung des Problems investiert hatten, spärlich auf. Hier einige Beispiele:[1]

Wirtschaftliche Nachwirkungen[Bearbeiten]

Durch die Hardware- und Softwareaktualisierungen, die zur Verhinderung des Y2K-Problems getätigt wurden, waren im Jahr 2000 viele Anwender mit aktuellen Plattformen ausgerüstet. Das löste in der folgenden Vierjahresperiode (Lebensdauer eines gängigen Bürogerätes) einen Einbruch beim Verkauf neuer Systeme und eine spürbare Rezession im Informatikbereich aus.

Die Kosten für die Wirtschaft waren gewaltig. So wurde beispielsweise vom Massachusetts Institute of Technology geschätzt, dass allein das US-amerikanische Medicare-Programm 500 Millionen US-Dollar zur Behebung des Fehlers ausgeben musste.[2] Der Gesamtaufwand für die Y2K-Projekte wurde von Gartner auf weltweit „bis zu 600 Milliarden US-Dollar“ geschätzt,[3] in großen Unternehmen erreichten die Kosten für Maßnahmen zur Überprüfung und Umstellung der Anwendungen zwei- bis dreistellige Millionenbeträge (Euro).[3]

Ähnliche Probleme[Bearbeiten]

  • Jahr-2010-Problem: zum Jahreswechsel 2009/2010 traten einige der hier prophezeiten Szenarien unerwartet ein. Kreditkarten und Debitkarten wurden nicht mehr als gültig erkannt und SMS-Nachrichten vordatiert.[4] Massenhaft wurden einwandfreie E-Mails fälschlicherweise als Spam behandelt.[5]
  • Jahr-2038-Problem: zum 19. Januar 2038 könnten wiederum ähnliche Probleme auftreten und bei EDV-Systemen zu Softwareausfällen führen. Dieses Problem dürfte jedoch auf EDV-Systeme beschränkt sein, die die Unixzeit als Zeitstandard benutzen. Ursache dafür ist, dass im Jahr 2038 die verwendete vorzeichenbehaftete 32-Bit-Ganzzahl nicht mehr zur Zeitdarstellung ausreicht und es somit zu einem arithmetischen Überlauf kommt.

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Y2K bug fails to bite. BBC NEWS, 1. Januar 2000, archiviert vom Original am 1. Januar 2000, abgerufen am 8. Mai 2012 (HTML, englisch).
  2. Delay Caused by Y2K Bug Will Cost Most Medicare Recipients
  3. a b nach Gartner in grin.com/de/e-book/96606/das-jahr2000-problem
  4. Das Jahr 2010 sorgt für IT-Probleme. Heise Verlag. 5. Januar 2010. Abgerufen am 6. Januar 2010.
  5. Jahr-2010-Problem im Spam-Filter von GMX. Heise Verlag. 1. Januar 2010. Abgerufen am 6. Januar 2010.