Das Jahr-2000-Problem: Tagebuch, Archiv Woche 30

Zum Abschluss der Woche und weil ich zu müde bin, irgendeine grosse Geschichte zu recherchieren, ein kleines Kuriosum:

Sie kennen wahrscheinlich Javascript, die von Netscape erfundende Programmiersprache, um kleine Programme, eben "Scripts", in HTML-Seiten aufnehmen zu können. Viele der "Year 2000 Clocks", die Ihnen auf Jahr-2000-Sites immer vorrechnen, wieviele Tage es noch dauert bis zum grossen Knall, sind z.B. mit Hilfe von Javascript realisiert.

Dafür, dass Javascript erst ein paar Jahre alt ist, erstaunt es ziemlich, wie ungeschickt die Sprache mit Datumsangaben umgeht.

Da gibt es die eingebaute Funktion getYear, um von einem Datum das Jahr zu ermitteln. Die Funktion könnte einfach stets eine vierstellige Jahreszahl zurückgeben, und alles wäre in Ordnung. Aber nein, weil das wahrscheinlich zu einfach wäre und dann ja jeder programmieren könnte, muss es ein wenig komplizierter sein:

Für Jahre im jetzigen Jahrhundert kommt eine zweistellige Jahreszahl zurück, also 98 für 1998. Ab 2000 (und neuerdings auch vor 1900) kommt die volle vierstellige Zahl zurück, für 2000 also 2000.

Man kann dies auf der Netscape-Site im Javascript Reference Manual nachlesen:
http://home.netscape.com/eng/mozilla/3.0/handbook/javascript/ref_f-g.htm#804 .

Diese - 'Tschuldigung - dämliche Definition führt bisweilen zu Verwirrungen, und es muss auf der Welt Tausende von Scripts geben, die das nicht richtig berücksichtigen.

Ein solches Beispiel hat kürzlich jemand im Usenet ausgegraben. Es ist darum bemerkenswert, weil es sich an einer Stelle befindet, wo es peinlicher fast nicht sein könnte: Auf der Homepage einer bekannten (und sonst auch sehr guten) Jahr-2000-Site, auf http://www.y2ktimebomb.com .

Weil Scripts natürlich ausgeführt und nicht angezeigt werden sollen, kriegen Sie den fehlerhaften Code nur zu sehen, wenn Sie sich die HTML-Source der Seite anzeigen lassen. Hierfür kennen fast alle Browser einen speziellen Befehl.

Die relevante Stelle in der Source ist die folgende:

    < SCRIPT >

    document.write("< center >< p align=center>< font size=3 .....

    document.write(myweekday + "< BR > 19" + year + "< /font >");

    < /SCRIPT >

    

Die festverdrahtete Neunzehn da ist einfach süss.

Ich will heute wieder mal dem ganz oben genannten Anspruch gerecht werden, mein Tagebuch sei nicht unbedingt etwas für Leute mit schwachen Nerven.

Russland ist ein riesiges Land, und es umfasst mehr Zeitzonen als jedes andere auf der Welt. Man sieht das z.B. auf der Karte unter http://www.halyava.ru/tunguska/russtime.htm sehr schön (Server steht in Russland, etwas Geduld, wenn die Karte nicht gleich kommt).

Stellen Sie sich nun das neue Jahrtausend vor, wie es am 1.1.2000 im Osten anbricht. Die Teile von Russland weit im Osten, z.B. mit der bekannten Stadt Wladiwostok, werden zuerst beglückt, während die Teile weiter westlich inklusive Hauptstadt Moskau erst ein paar Stunden später durch die Drehung der Erde ebenfalls hinüberrutschen.

So ziemlich über ganz Russland verteilt gibt es Abschuss-Basen für ballistische Atomraketen, also auch weit im Osten. Stellen Sie sich nun den Steuer-Computer in einer solchen Basis vor, wie er sich wegen eines Jahr-2000-Fehlers sang- und klanglos verabschiedet. Damit ist auch seine Verbindung zum Zentralcomputer in Moskau tot.

Das Programm in jenem Zentralcomputer läuft noch, da es sich nach wie vor im alten Jahrtausend befindet. Es wird also bemerken, wie es zu einer Abschuss-Basis nach der anderen im fernen Osten den Kontakt verliert.

Was mag der Programmierer für diesen Fall dem Programm als mögliche Interpretation mitgegeben haben? Ich weiss nicht, was Sie für eine erste Idee haben. Wie wär's mit meinem Vorschlag: Massenhaft verlorene Kontakte zu Basen im Osten = zerstörte Basen durch massiven chinesischen Erstschlag.

Ok, ok, dieses Szenario ist vielleicht nicht sehr wahrscheinlich, und es löst ja wohl auch nicht der Computer alleine den Gegenschlag aus, sondern irgend ein Mensch wird schon noch beurteilen, ob ein chinesischer Angriff plausibel ist oder nicht. Und überhaupt wird sich die russische Armee schon noch mit dem Thema "Jahr 2000" auseinandersetzen in der Zeit, die bleibt bis zum Datumswechsel.

Allerdings heisst das nicht, man müsse sich überhaupt keine Sorgen machen. Das beweist ein Ereignis Anfang 1995.

Am 25. Januar 1995 aktivierte der russische Präsident zum ersten Mal überhaupt sein "elektronisches Köfferchen", mit dem er die russischen Atomraketen zum Start freigeben kann. Eine amerikanische wissenschaftliche Rakete, gestartet in Norwegen, hatte die Russen in helle Aufregung versetzt. Wie es sich gehört, war dieser Start den Russen vorher angekündigt worden, aber diese Ankündigung hatte irgendwie ihr Ziel nicht erreicht.

Ein paar bange Minuten lang wartete Jeltsin mit seinem für den Ernstfall aktivierten Köfferchen, bis die Meldung von den Radarstationen kam, dass die Rakete nicht Kurs auf Russland nehme.

Diese unter http://www.sciam.com/1197issue/1197vonhippel.html nachzulesende auch vom Jahr-2000-Problem unabhängig interessante Geschichte zeigt sehr schön die Nervosität der Russen und die Fehleranfälligkeit ihres militärischen Apparates selbst unter normalen Umständen.

Wie eine Reihe von Artikeln im amerikanischen Magazin Forbes zeigen, machen sich die Amerikaner schon Gedanken darüber, wie das aussieht mit den russischen Atomraketen und dem Jahr-2000-Problem. Wenn ich sehe, wie sich der amerikanische Militär-Apparat schwertut damit (siehe 26. Juni), mache ich mir über den russischen erst recht Sorgen.

Lesen Sie ruhig (d.h. wenn Sie es schaffen, ruhig zu bleiben) etwas unter http://www.forbes.com/tool/html/98/jul/0717/ . Ein Zitat von da, als Appetit-Häppchen:

If this were a movie, it would have to be entitled, Dr. Strangelove: Or how I learned to stop worrying and love the millennium bug.

Schon vor einiger Zeit, am 2. April, habe ich eine sogenannte "Silver Bullet" für das Jahr-2000-Problem vorgestellt, eine Methode, die von sich behauptet, das Problem auf wundersame Weise mit geringem Aufwand und kaum Nebenwirkungen aus der Welt zu schaffen. Heute möchte ich eine zweite vorstellen.

Kernpunkt des Problems ist die Tatsache, dass viele Programme mit Daten im Jahr 2000 und später nicht klarkommen. Was liegt da näher, als es einfach gar nicht soweit kommen zu lassen? Stellen wir doch einfach am 31.12.1999 um Mitternacht die Uhren der Computer um ein paar Jahre zurück! Problem gelöst, oder?

Es gibt einige Leute, die diesen Ansatz vehement vertreten. Ein schönes Beispiel ist http://sitewave.net/y2ksb/s56p555.htm . Die Firma TOCS hat sogar für eine bestimmte Methode, die Uhr zurückzustellen, zusammen mit ein paar begleitenden Tools ein Patent in den USA erhalten: http://www.tocs.com/a2.htm .

Favorisiert wird das Vorgehen, die Uhr 28 Jahre zurückzustellen. Aus 2000 wird also 1972. Der Grund hierfür ist, dass sich der Kalender alle 28 Jahre wiederholt: Der 1.1.1972 war ein Samstag, wie es der 1.1.2000 sein wird; zudem war 1972 ein Schaltjahr wie 2000 auch. Ein paar bewegliche Feiertage wie Ostern, die trotz allem nicht stimmen, kann man verkraften.

Sie werden es ahnen: Ich bin nicht überzeugt, dass dies die lang gesuchte wundersame Lösung ist. Warum nicht, ist aber gar nicht so einfach zu erklären. Es gibt meines Wissens kein einzelnes, schlagendes Argument gegen diese Methode. Man trifft nur auf immer mehr und noch mehr Probleme, wenn man sich konkret überlegt, wie das funktionieren soll.

Will man die Uhr auf 1972 zurückstellen und ohne weitere Massnahme mit dem System in diesem Zustand arbeiten, ergeben sich eine Reihe handfester Schwierigkeiten. Wenn die Leute beim Erfassen von Daten 1971 statt 1999, 1972 statt 2000, usw. eingeben müssen, und überall auf Ausdrucken diese seltsamen Jahreszahlen auftauchen, wird das kaum praktikabel sein. "Dieser Scheck ist gültig bis zum 21. Juli 1972" "Wir fordern Sie höflich auf, die Rechnung bis zum 21. Juli 1972 zu bezahlen" ... wohl kaum!

Besser ist, man lässt das Programm in den Siebziger-Jahren rechnen, lässt dies aber nach aussen nicht sichtbar werden. Dieser Ansatz wird Encapsulation genannt. Man subtrahiert überall dort, wo Jahreszahlen in das System hineinkommen, gleich einmal 28 Jahre. Ueberall dort, wo Jahreszahlen wieder herauskommen, zählt man umgekehrt 28 Jahre dazu.

Das ist aber leichter gesagt als getan. Um dies zu erreichen, muss man zwar am fraglichen Programm selbst wohl nichts ändern, aber "darumherum". Irgendwo müssen ja diesen kleinen Stücke Code, welche die Jahreszahlen-Magie vollbringen, im System eingepflanzt werden. Dies ist alles andere als trivial und bei grossen Systemen wie jede andere Aenderung aufwendig und fehleranfällig.

Eines der vielen weiteren Probleme: Wenn ein Programm mit dem nächsten Jahrhundert nicht klarkommt, tut es dies ebensowenig mit dem vorherigen, neunzehnten Jahrhundert. Bei 1928 ist also Schluss: 1927 minus 28 ergibt zweistellig gerechnet 99, was das Programm als 1999 statt als 1899, also falsch bearbeiten wird. Geburtstage von Leuten älter als 72 Jahre z.B. können also nicht gespeichert werden.

Und wehe, irgendein Programmierer ist auf die Idee gekommen, irgendwelche direkte Vergleiche auf Jahreszahlen einzubauen, "fix verdrahtet", wie das in unserem Jargon heisst: "Wenn Datum später als 1.1.1998, dann alter Prozentsatz, sonst neuer Prozentsatz". Solcher Code dürfte gar nicht so selten sein und fällt natürlich samt und sonders auf die Nase. Im obigen Beispiel müsste ja jetzt ab 1970 der neue Prozentsatz angewendet werden.

Noch ein paar Gegenargumente mehr findet man unter http://y2kwatch.com/showart.php3?idx=63&rtn=y2kman.htm .

Es mag sein, dass man einige Programme mit dieser Methode erstaunlich einfach jahr-2000-fähig machen kannen. Es ist aber auch sicher, dass es eine ganze Menge von Computersystemen und Programmen gibt, die sich definitiv hierfür nicht eignen. Bei Anwendung der Methode kommt also noch die Arbeit hinzu, abzuklären, welche dies sind.

Alles in allem ist die Methode weit davon entfernt, uns vor dem Jahr-2000-Problem zu retten.

Sie wissen doch, wie das ist mit dem Sommerloch im Fernsehen: Alle guten Sendungen haben Sommerpause, stattdessen endlose Wiederholungen zweit- und drittklassiger Ware. Nun, was das Fernsehen kann, kann ich auch: Hier kommt meine Wiederholung.

Vor etwas mehr als einem Vierteljahr, am 1. April, habe ich berichtet, was sich ergibt, wenn man im Schweizer WWW per Suchmaschine nach Informationen über das Jahr-2000-Problem sucht. Ich habe damals das Resultat als ziemlich niederschmetternd beurteilt.

Ein Vierteljahr ist eine halbe Ewigkeit bei einem so grossen Problem, das so unmittelbar bevorsteht, so dass ich einen erneuten Blick auf das Schweizer WWW für gerechtfertigt halte. Also, beginnen wir:

http://sear.ch/....&q=Jahr+2000+Problem&engine=Schweiz

Obige noch recht unspezifische Suche, die auch Seiten liefert, auf denen z.B. nur "Jahr" vorkommt, liefert statt 61659 Treffer wie am 1. April jetzt 71332 Treffer.

http://sear.ch/....&q=Jahr+AND+2000+AND+Problem&.....

Das ist schon besser: Statt nur 980 Seiten mit allen drei Stichworten gleichzeitig gibt es nun 1766 solche Seiten. Beachtlich, fast eine Verdoppelung.

http://Sear.ch/....&q=Jahr+NEAR+2000+NEAR+Problem&....

Resultat dieser dritten Suche: Die Anzahl Seiten, auf denen es mit grosser Wahrscheinlichkeit tatsächlich um das Jahr-2000-Problem geht, stieg von 237 auf 340. Na ja. (Zu dieser Vermehrung um gut 100 Seiten habe ich selbst schätzungsweise etwas mehr als 20 beigetragen.)

Wie steht das Rennen zwischen Vampiren, Enzian, Rückenschmerzen und Jahr-2000-Problem? "Vampire" stieg von 560 auf 743, "Enzian" von 250 auf 388, und "Rückenschmerzen" von 310 auf, na so was, auch 388. Alle drei liegen also immer noch vor dem Jahr-2000-Problem.

Fazit: Auf dem Schweizer WWW ist das Jahr-2000-Problem immer noch ein Thema unter "Ferner liefen". Aber was ist auch anderes zu erwarten, jetzt, im Sommerloch?

Das Jahr-2000-Problem ist ein unhandliches Ding. Es hat so viele Facetten und es gehen so viele Entwicklungen durcheinander, dass es extrem schwierig ist, aufgrund der jetzt vorhandenen Informationen Voraussagen zu machen, wie der Januar 2000 wirklich wird. Zudem liegt das Problem zum allergrössten Teil noch vor uns. Jeder, der Lust hat, kann darum behaupten, es werde nichts Schlimmes passieren, und niemand kann das Gegenteil beweisen.

Ich bin deshalb immer auf der Suche nach Beispielen, die bereits geschehen und damit nicht bezweifelbar sind, die für jedermann verständlich und hübsch übersichtlich sind. Ich habe immer noch Hoffnung, dass nach dem Studium mehrerer solcher Beispiele (für eine Liste siehe Kategorie Bereits geschehen) eigentlich vielen Leuten klar werden müsste, was für das Jahr 2000 zu befürchten ist.

Ich möchte heute ein besonders schönes neues Beispiel dieser Kategorie vorstellen.

Am 6. Juli war es soweit: Der teuerste Flughafen der Welt, zugleich derjenige mit dem grössten Passagier-Terminal der Welt, und auch derjenige mit dem grössten Fracht-Umschlag-Volumen der Welt, wurde in Betrieb genommen: Chek Lap Kok, der neue, ins Meer hinausgebaute Flughafen von Hong Kong.

Nun, was als Triumph gedacht war, geriet innert kürzester Zeit zu einem Riesen-Katzenjammer. Ein Bericht darüber fasst das so zusammen - siehe http://www.businesstoday.com/techpages/y2khk071398.htm :

Hunderte von Linienflügen hatten Verspätung, Tausende von Gepäckstücken gingen verloren, verderbliche Güter im Werte von Millionen von Dollars blieben liegen und verfaulten. Ein 20-Milliarden-Dollar-Wunder der Ingenieurskunst, angepriesen als der fortschrittlichste Flughafen der Welt, bot ein Niveau an Service, das man eher von einer Landung im Kosovo oder im Sudan erwarten würde.

Verschiedenste Faktoren haben zum Durcheinander beigetragen, aber nicht funktionierende oder fehlerhafte Computersysteme machten einen grossen Teil aus. Am meisten Probleme verursachte das supermoderne, hochcomputerisierte "baggage handling system", das zeitweise ganz ausfiel und die Gepäck-Abfertigung in ein Chaos stürzte.

Daneben gab es auch so nette Ueberraschungen wie nicht funktionierende Anzeigetafeln und in der Folge davon eine Menge Passagiere, die einfach nicht rechtzeitig herausfinden konnten, wo sie hin mussten. Die Hälfte der öffentlichen Telefone in den Terminals funktionierten nicht, und die Billett-Automaten für die Flughafen-Schnellbahn spielten verrückt.

Die grösste Fracht-Transport-Firma Hong Kongs kam zum Schluss, dass mit den Programmen an den Fracht-Terminals einfach nicht zu arbeiten sei und verlegte ihre Operationen kurzerhand wieder zurück zum alten Flughafen Kai Tak. Bis zum heutigen Tag wird nun die ganze Fracht zwischen den beiden Flughäfen hin- und hergekarrt, weil die Flugzeuge natürlich am alten Ort nicht mehr landen können.

Wie war doch das schon wieder mit den Terminen? Ursprünglich sollte der Flughafen am 1. Juli 1997 eröffnet werden, pünktlich zur Rückgabe Hong Kongs an China. Schlussendlich wurde der 6. Juli 1998 als Termin festgelegt.

Von verschiedenen Seiten war gewarnt worden, dass dieser Termin zu früh sei, dass die Systeme allerfrühestens im September einigermassen getestet sein würden. Nun, Regierungen sind sich gewohnt, dass ihren Anweisungen Folge geleistet wird, und wenn man befiehlt, der Flughafen habe am 6. Juli 1998 fertig zu sein, wird das wohl so sein. http://www.computerworld.com/home/news.nsf/all/9807131airport

Sie können sich jetzt das Jahr 2000 wahlweise vorstellen A) wie der Flughafen von Hong Kong am 6. Juli 1998, oder B) wie der Flughafen von Hong Kong, wie wenn er am 1. Juli 1997 eröffnet worden wäre, als die meisten noch mitten in der Arbeit waren. Sich das Jahr 2000 wie einen gutlaufenden Flughafen Zürich-Kloten oder Frankfurt vorzustellen, wird hier als Option nicht angeboten.

Interessant ist übrigens, dass sich jetzt bei solchen Ereignissen praktisch immer jemand findet wie der Autor des ersten erwähnten Artikels in "BusinessToday", der den Zusammenhang mit dem Jahr-2000-Problem klar erkennt. Fragt sich nur, ob die Erkenntnis nicht bereits zu spät kommt.