Das "Jahr-2000-Problem"
Betrug oder Bedrohung?

von Peter Marksteiner (Ausgabe 99/2, Juni 1999)

 

Weniger als 200 Tage trennen uns vom 1. Jänner 2000 - dem Tag, an dem das vielzitierte "Jahr-2000-Problem"1) akut wird. Die Meinungen darüber gehen weit auseinander: Manche bestreiten überhaupt die Existenz des Problems und halten alle Lösungsmaßnahmen für Schwindel von gerissenen Geschäftemachern; andere beschwören apokalyptische Schreckensvisionen herauf, denen zufolge am 1. Jänner 2000 pünktlich um Mitternacht nicht nur alle Computer den Geist aufgeben, sondern auch alle Elektrogeräte - was aber relativ egal ist, weil zur gleichen Zeit Strom-, Gas- und Wasserversorgung zusammenbrechen und sämtliche Atomraketen losschlagen.

Das Problem ...

Die größten Schwierigkeiten hat ohne Zweifel die kommerzielle Datenverarbeitung zu erwarten, die hauptsächlich mit Transaktionen arbeitet: Jede Änderung eines Datenbestandes (Ein- und Auszahlungen, Buchungen usw.) ist eine Transaktion, bei der Datum und Uhrzeit (der sogenannte timestamp) notiert werden. Eine der Hauptaufgaben der kommerziellen EDV ist es, solche timestamps zu vergleichen und Differenzen zu bilden. Wenn beispielsweise jemand am 17. November 1997 einen Betrag auf ein Konto einzahlt und am 3. Jänner 1999 wieder abhebt, so muß man zur Berechnung der Zinsen wissen, wie viele Tage zwischen diesen beiden Daten verstrichen sind. Das ist zwar keine höhere Mathematik, aber wegen der unterschiedlichen Länge der Monate und wegen Komplikationen wie Schaltjahren relativ umständlich und fehleranfällig.

Nun wird bei vielen Datumsangaben die Jahreszahl zweistellig, d.h. ohne Angabe des Jahrhunderts, abgespeichert. Diese auf den ersten Blick so harmlose und unscheinbare Tatsache ist die Ursache für das Jahr-2000-Problem. Betrachten wir wieder ein Beispiel: Jemand mietet am 10. Dezember 1999 ein Auto und gibt es am 15. Jänner 2000 zurück. Ein Buchhaltungsprogramm kommt zu dem Schluß, daß zwischen 10-12-99 und 15-01-00 fünf Tage, ein Monat und minus 99 Jahre verstrichen sind, und anstatt dem Kunden die Miete für 36 Tage zu verrechnen, schreibt es ihm die Miete für 36488 Tage gut.

Zeit- und Datumsangaben gibt es aber nicht nur in der kommerziellen EDV, sondern praktisch überall, und daher können am 1. Jänner 2000 überall Schwierigkeiten auftreten. Es ist nicht nur ein Softwareproblem; auch manche clock chips verwenden zweistellige Daten. Ihr PC zu Hause kann ebenso betroffen sein wie alle möglichen Steuerungssysteme in Industrie, Verkehr und Nachrichtentechnik. Viele Programme überprüfen, ob gewisse Ereignisse zu vorgeschriebenen Zeiten eintreten - beispielsweise ein Zugsicherungssystem, bei dem der Lokführer in regelmäßigen Abständen eine Taste drücken muß. Ein solches System mit einem Jahr-2000-Problem könnte um Mitternacht des 31. Dezember 1999 eine Schnellbremsung einleiten, weil es glaubt, das letzte Lebenszeichen vor hundert Jahren erhalten zu haben. Auf ähnlichen Prinzipien beruhen die Prognosen jener Pessimisten, die mit unabsichtlichen Nuklearschlägen rechnen. Gott sei Dank ist das äußerst unwahrscheinlich - immerhin wird dieses Problem soweit ernst genommen, daß ansonsten verfeindete Atommächte miteinander kooperieren, um solch fatale Irrtümer auszuschließen.

... und seine Ursachen

Wenn zweistellige Jahreszahlen so viel Ärger machen, warum werden sie dann so häufig verwendet? Oft hört man die Erklärung, daß viele Programme und Datenbanken aus der Frühzeit der EDV stammen, als Haupt- und Plattenspeicher extrem teuer waren und Speicherplatz gespart wurde, wo es nur ging. Diese Erklärung ist sicherlich richtig, gilt aber nur für einen relativ kleinen Teil des Problembereichs. Microsoft Windows 95 beispielsweise (von dem böse Zungen behaupten, daß es bereits im Namen ein Jahr-2000-Problem habe) wurde erst vor wenigen Jahren entwickelt, braucht aber eine Menge Korrekturen, um vollständig fit für das Jahr 2000 zu sein.

Eine weitaus größere Rolle spielen Faulheit, Bequemlichkeit, Gedankenlosigkeit und mangelnde Voraussicht: Viele Programme wurden für einen einzigen konkreten Anlaß geschrieben - es gab daher keinen Grund, besonders weit in die Zukunft zu blicken. Gerade solche Programme werden aber (sehr zum Erstaunen ihrer Autoren) oft noch nach Jahren und Jahrzehnten verwendet.

Die häufigste Ursache ist aber wohl Gewohnheit: Bei fast allen Datumsangaben im täglichen Leben ist die Angabe des Jahrhunderts überflüssig, weil ohnehin klar ist, was gemeint ist. Die Zeitspanne eines Jahrhunderts liegt üblicherweise außerhalb der menschlichen Lebenserfahrung. Überall werden Daten mit zweistelligen Jahreszahlen verwendet: Beispielsweise beim Ablaufdatum von Kreditkarten, beim Geburtsdatum als Bestandteil der Sozialversicherungsnummer, beim Inskriptionsjahr als Bestandteil der Matrikelnummer - oder auf der Titelseite des Comment.

Ein Mensch kann sehr gut aus dem Zusammenhang erraten, was gemeint ist; ein Computer kann das gar nicht. Deswegen beinhaltet eine vollständige Lösung des Jahr-2000-Problems auch das Design von Benutzerschnittstellen, bei denen einerseits die Ein- und Ausgabe von Daten in einem Format erfolgt, das den Anwendern vertraut ist, und andererseits alle Daten intern so abgespeichert und verarbeitet werden, daß es keinerlei Unsicherheiten und Zweideutigkeiten gibt. Vierstellige Jahreszahlen allein sind kein Allheilmittel: Das Unix-Programm cal beispielsweise (ein primitiver Kalender) verwendet konsequent vierstellige Jahreszahlen. Gerade deswegen haben aber schon viele Unix-Benutzer ihre Termine versäumt: Mit dem Befehl cal 5 98 erhält man nämlich keinen Kalender für den Mai 1998, sondern für den Mai 98 nach Christus (vollkommen korrekt nach dem damals gültigen Julianischen Kalender - obwohl damals die Zeitrechnung nach Christi Geburt noch nicht üblich war und sich auch die Wochentage noch nicht überall im Römischen Reich durchgesetzt hatten).

Schwierigkeiten mit nicht eindeutigen Daten kann es zu jeder Zeit geben, am 1. Jänner 2000 werden sie nur besonders massiv auftreten. Innerhalb der kommerziellen EDV, die - wie erwähnt - am meisten mit dem Problem zu kämpfen hat, ist der Stand der Vorbereitung sehr unterschiedlich: Manche Branchen (z.B. Lebensversicherungen) haben mit Geburtsdaten im 19. Jahrhundert und bereits seit vielen Jahren mit Vertrags-Ablaufdaten im 21. Jahrhundert zu tun und sind daher schon seit langem auf den Jahrtausendwechsel eingestellt.2) Andere Branchen arbeiten mit kürzeren Zeitspannen und sind sich des Problems erst seit wenigen Jahren oder Monaten bewußt - wenn überhaupt. Besonders in den letzten beiden Jahren sind viele Fehler bekannt geworden (z.B. weigerten sich viele Kassen, Kreditkarten mit einem Ablaufdatum im Jahr 00 anzunehmen); ein Großteil davon konnte aber bereits behoben werden. Zu diesem Thema gibt es zahlreiche Anekdoten: Allgemein bekannt sind die Geschichten von 106-jährigen, die aufgefordert wurden, die Volksschule zu besuchen. Angeblich hat das Lagerhaltungssystem einer englischen Supermarktkette, das abgelaufene Konserven mittels Scanner automatisch aussortiert, große Mengen an frisch gelieferten Tomatenkonserven mit Ablaufdatum im 21. Jahrhundert weggeworfen. Der Lieferant bemerkte das zwar, sagte aber nichts, weil sein Kunde plötzlich Unmengen von Tomatenkonserven kaufte...

Datumsformate

Wie gravierend die Jahr-2000-Probleme sind, hängt natürlich von der verwendeten Software ab. Es gibt sehr unterschiedliche Methoden, Daten abzuspeichern, ein- und auszugeben und zu verarbeiten. Oracle beispielsweise, ein modernes und sehr weit verbreitetes Datenbanksystem, verwendet ein eigenes Datumsformat, das es ermöglicht, Daten zwischen 4712 vor Christus und 9999 nach Christus eindeutig abzuspeichern. Trotzdem haben viele Oracle-Anwendungen massive Probleme: Die Ein- und Ausgabe kann in fast jedem beliebigen Format erfolgen, und aus Bequemlichkeit werden oft nur zweistellige Jahreszahlen angegeben.

Das Betriebssystem Unix verwendet zur Zeitrechnung die Zahl der Sekunden, die seit dem 1. Jänner 1970 0:00 UTC (Universal Time Coordinated, auch bekannt als Greenwich Mean Time) verstrichen sind. Dieses Format hat keinerlei Probleme mit dem Jahr 2000 (für ein Unix-System ist der 1. Jänner 2000 0:00 MEZ gleich 946681200), mit Winter-/Sommerzeit-Umstellungen und verschiedenen Zeitzonen. Leider benutzt Unix zum Umrechnen dieser internen Zeitangaben in ein lesbares Format für die Ein- und Ausgabe aber eine Datenstruktur, in der nicht das Jahr angegeben wird, sondern das Jahr minus 1900 (also 99 heuer, 100 im Jahr 2000). Sind alle betroffenen Applikationen richtig programmiert, gibt es keine Probleme - aber diese Datenstruktur macht es sehr leicht, falsche Programme zu schreiben. Dieses Datumsformat ist ein typisches Beispiel für Kurzsichtigkeit und Gedankenlosigkeit: Die vollständige Jahreszahl hätte hier nicht ein Bit mehr an Speicher benötigt, aber sehr viele Fehler und sehr viel Arbeit erspart.

Das Betriebssystem AIX, eine von IBM entwickelte Unix-Variante, verwendet für manche Zwecke das (meiner Meinung nach besonders absurde) Datumsformat MMddhhmmyy, also z.B. 0304050607 für den 4.März 2007, 5:06 Uhr. Eine Applikation, die Ablaufdaten von Benutzungsberechtigungen in diesem Format inkorrekt verarbeitete, war die Ursache des ersten Jahr-2000-Problems am EDV-Zentrum: Im Jänner 1998 wurden die ersten Mailbox-Benutzungsberechtigungen mit einer Gültigkeit bis zum Jahr 2000 vergeben, und dieses Programm war der Ansicht, sie wären bereits abgelaufen.

Wie kann man sich vorbereiten?

Die vollständige Lösung eines eventuellen Jahr-2000-Problems ist nur dann möglich, wenn sämtliche Teile eines Betriebssystems oder einer Applikation sorgfältig nach zweistelligen Jahreszahlen durchsucht werden. Einfaches Ersetzen durch vierstellige Jahreszahlen ist meistens nicht möglich, deshalb muß oft zusätzliche Programmlogik eingebaut werden (z.B.: Ist die Zahl kleiner als 30, interpretiere sie als Jahreszahl im 21. Jahrhundert, ansonsten als Jahreszahl im 20. Jahrhundert). Programme dieser Art sind oft "Zeitbomben", die dann z.B. im Jahr 2030 ohne Vorwarnung plötzlich nicht mehr funktionieren.

Aus Zeitgründen muß man sich manchmal mit Näherungslösungen zufriedengeben: Wenn eine Firma heute zu dem Schluß kommt, daß sie noch zwei Jahre braucht, um ihre EDV-Systeme vollständig nach Jahr-2000-Problemen zu durchforsten, dann bleibt ihr nichts anderes übrig, als die Suche auf die wichtigsten Bereiche zu beschränken und zu hoffen, daß schon nichts passieren wird. Essentieller Bestandteil der Jahr-2000-Vorbereitung von Firmen ist es, die Systeme zu testen, indem man die Systemzeit auf den 31. Dezember 1999 setzt und beobachtet, was beim Übergang auf das Jahr 2000 passiert. Manche Systeme, die den Wechsel ins Jahr 2000 absolut nicht schaffen, werden als Notlösung die Systemzeit auf das Jahr 1972 zurücksetzen - dort stimmen die Wochentage mit denen des Jahres 2000 überein.

Die Softwarehersteller garantieren meistens, daß ihre Programme im Jahr 2000 und danach wie bisher funktionieren, wenn alle erforderlichen Korrekturen angebracht wurden (Links zu Y2K-Sites der wichtigsten Hersteller finden Sie im Kasten am Ende dieses Artikels). Wenn ein Betriebssystem oder eine Datenbank vom Hersteller als Y2K-compatible bezeichnet wird, heißt das noch lange nicht, daß EDV-Systeme, die diese Software verwenden, im Jahr 2000 keine Probleme bekommen. Das ist nur dann der Fall, wenn alle zusätzlichen Komponenten (Software von anderen Herstellern, selbstgeschriebene Programme und Prozeduren usw.) sich an die dokumentierten Schnittstellen halten. Manchmal beschränken sich die "Jahr-2000-Korrekturen" auf Anpassungen der Dokumentation an die Realität. Wurde z.B. früher ein Datumsfeld mmddyy als "Monat-Tag-Jahr" beschrieben, so erfahren wir heute, daß yy "die letzten beiden Ziffern der Jahreszahl von Daten zwischen dem 1. Jänner 1939 und dem 31. Dezember 2038" darstellt. Die meisten Softwarehersteller schweigen sich jedoch aus, was passiert, wenn man die Korrekturen nicht anbringt: Funktioniert das ganze System nicht, oder nur einige "unbedeutende Kleinigkeiten"? Was für einen Kunden eine unbedeutende Kleinigkeit ist, kann für den anderen essentiell sein - deshalb sind die Hersteller hier sehr vorsichtig mit Aussagen. Die meisten PC-Systeme werden wohl im großen und ganzen weiter funktionieren; trotzdem sollten Sie sicherheitshalber alle Jahr-2000-Korrekturen anbringen.

Das Jahr-2000-Problem hat aber noch andere Facetten: Selbst wenn Applikationen alle zweistelligen Jahreszahlen vollkommen korrekt verarbeiten, gibt es Schwierigkeiten bei deren Interpretation. Schon jetzt ist nicht ganz eindeutig, was mit 03-07-99 gemeint ist - hierzulande wird das als 3. Juli 1999 interpretiert, in den USA als 7. März. Nachdem die meisten Computerprogramme in den USA geschrieben werden, findet sich die uns unlogisch vorkommende Reihenfolge Monat-Tag-Jahr auch in Europa in etlichen Softwareprodukten. Ab dem Jahr 2001 wird die Mehrdeutigkeit noch schlimmer: Es gibt sechs mehr oder minder plausible Möglichkeiten, ein Datum wie 02-03-01 zu interpretieren. Wann läuft eine Kreditkarte mit Ablaufdatum 01/02 ab, im Februar 2001 oder im Jänner 2002? Ohne Zweifel werden solche Fragen zu zahlreichen Unsicherheiten, Mißverständnissen und Reklamationen führen.

Ein weiteres kleines Problem ist am 29. Februar 2000 zu erwarten. Nach dem derzeit gültigen Gregorianischen Kalender ist jedes Jahr ein Schaltjahr, dessen Jahreszahl durch vier teilbar ist. Ausnahmen sind Jahre, die durch 100, aber nicht durch 400 teilbar sind. Die Jahre 1700, 1800 und 1900 waren daher keine Schaltjahre, 1600 war eines und 2000 wird wieder eines sein (der Gregorianische Kalender wurde 1582 eingeführt). Nicht alle Programmierer sind mit diesen Feinheiten vertraut - daher gibt es etliche Softwareprodukte, die von der irrigen Annahme ausgehen, der Februar 2000 habe nur 28 Tage.

Was wird passieren?

Zum Abschluß wage ich eine Prognose: Ich bin zuversichtlich, daß die meisten Menschen von der großen Krise gar nichts oder nur sehr wenig bemerken werden und daß größere Katastrophen ausbleiben werden - dies allerdings nur deshalb, weil seit Jahren intensiv an dem Problem gearbeitet wird und Unsummen darin investiert wurden. Während der Großteil der Menschheit den Jahrtausendwechsel 3) feiert, werden Computerfachleute auf der ganzen Welt hektisch daran arbeiten, ihre Systeme sicher durch die kritische Phase zu bringen. Der 31. Dezember ist ein Freitag; wer irgendwie kann, wird an diesem Freitag möglichst früh alle Operationen einstellen und erst am Montag, dem 3. Jänner 2000, wieder aufnehmen. Der 1. Jänner beginnt im Pazifik an der Datumsgrenze; von den Ländern mit hochentwickelter EDV-Infrastruktur ist als erstes der südostasiatische Raum (v.a. Japan) betroffen. Einige Stunden später findet der Jahreswechsel in Europa statt, und während sich die meisten Europäer nach einer langen Nacht - sei es bei der Silvesterparty oder vor dem Bildschirm - ausschlafen, beginnt auch für die USA das Jahr 2000.

Kleine und mittlere Krisen wird es aber ohne Zweifel geben: Mit Verzögerungen von ein paar Tagen bei diversen Lieferungen, Gehaltszahlungen, Zinsengutschriften und dergleichen ist durchaus zu rechnen, und manche Firmen werden aufgrund ihrer EDV-Probleme wirtschaftlich nicht überleben. Bei privaten EDV-Geräten wird es des öfteren zu kleineren Funktionsstörungen kommen (einzelne Applikationen könnten sich etwas seltsam verhalten - z.B. Mailprogramme, die Nachrichten nicht richtig nach dem Datum sortieren); von Totalausfällen sind aber wohl nur sehr veraltete Systeme bedroht. Relativ problemlos wird das Internet das Jahr 2000 überstehen. Am EDV-Zentrum der Uni Wien wird sehr viel Arbeit investiert, um die Verwaltungsapplikationen auf der VM-Rechenanlage fit für das Jahr 2000 zu machen. Ansonsten verwenden die Services des EDV-Zentrums moderne Hard- und Software; die meisten lokal entwickelten Applikationen wurden erst in den letzten Jahren geschrieben und sollten weitgehend frei von Jahr-2000-Problemen sein.

Ohne Zweifel wird die Software-Krise im Jahr 2000 aber auch positive Auswirkungen haben: An vielen Orten sind vollkommen veraltete Programme im Einsatz, weil die Unternehmen die Kosten und den Aufwand der Umstellung scheuen. Wenn diese Produkte im Jahr 2000 den Geist aufgeben, werden viele Unternehmen zur Modernisierung gezwungen sein.

 

 

1) im Computerjargon oft Y2K genannt (Y für year, K für kilo)

2) Das erste verbürgte Jahr-2000-Problem gab es am 1. Jänner 1970; es betraf einen Kredit mit dreißigjähriger Laufzeit.

3) Nachdem das erste Jahrtausend mit dem Jahr 1 beginnt, ist eigentlich das Jahr 2001 das erste Jahr des dritten Jahrtausends.