Erstaunlicher Weise findet das Problem im deutschen Internet so gut wie keine Beachtung, außer den Aktivitäten um Prof. Knolmeyer an der ETH-Zürich (www.ie.iwi.unibe.ch/zeit) sind nur wenige Quellen auszumachen, wie ein Blick in den Suchbaum von Yahoo! (www.yahoo.de) für das Jahr 2000 schnell verdeutlicht. Im amerikanischen Raum tut sich da erheblich mehr, wie in der Newsgroup comp.software.year-2000 zu beobachten ist. Auch auf dem Server www.year2000.com finden sich vielfältige Informationen und Verweise auf weitere Quellen.

Anmerkung am 1. September 1999: Im Laufe der vergangenen Zeit hat sich auch in Deutschland ganz erheblich etwas getan im Zusammenhang mit dem Jahr 2000 Problem. Und das nicht nur im Hinblick auf die Sylvesterparties. Aktuelle Infos gibt es bei der Initiative 2000 (www.initiative2000.de (t)).

Anmerkung am 10. April 2000: Allem Anschein nach hatte sich Deutschland wie auch der Rest der Welt hinreichend vorbereitet und der Fehler hat nicht die Auswirkungen erreicht, die viele erwartet (erwünscht?) hatten.

In vielen Informationssystemen - Anwendungen wie Datenbeständen - wird das Jahr nur durch die beiden letzten Ziffern YY der vierstelligen Jahreszahl CCYY repräsentiert. Dies ist auf mehrere Gründe zurückzuführen (vgl. /Knolmeyer97/):

• Eine zweistellige Jahresrepräsentation erfordert gegenüber vierstelligen Angaben weniger Platz und verursacht daher kurz- bis mittelfristig weniger Kosten. Dies war früher wichtiger als heute. So ist eine Darstellung vierstelliger Jahreszahlen in COBOL75 gar nicht möglich gewesen.
• Die so entstandenen Datenbestände sollten zur Vermeidung von Redundanzen wiederverwendet werden, daher benutzen auch jüngere Anwendungen zweistellige Jahreszahlen.
• Standardisierungsorganisationen stellen zweistellige Jahresangaben als zulässige Variante dar (z.B. in ISO 8601).
• Viele Entwickler ahnten nicht, dass die von ihnen entwickelten Programme noch im Jahr 2000 im Einsatz sein würden.
• Benutzer ziehen kürzere Dateneingaben längeren vor. Sind bei der Erfassung großer Datenvolumina zahlreiche Jahreszahlen einzugeben, so ist die zweistellige Eingabe wesentlich bequemer. Auf Berichten und Bildschirmen wurde auf die Angabe des Jahrhunderts aus Platzgründen auch häufig verzichtet, welches dazu führt zweistellige Jahreszahlen weiterzuverwenden oder - häufig gar fix programmiert: ADD 1900 TO Eingabe-Jahr - dass das Jahrhundert vom Programm gesetzt wird.

Einige der Gründe lassen sich auch auf das Internet anwenden. So war Bandbreite von jeher ein knappes Gut und es kann daher nicht verwundern, wenn das Jahrhundert eingespart wurde. Technisch wurde die meisten der älteren Knoten ausgetauscht, so dass es auf der Protokollebene kein Problem geben sollte. Und selbst wenn, es wird sich vermutlich auf ein recht kleines Zeitfenster beschränken, nämlich wenn genau zum Jahreswechsel kommuniziert wird, können sich aufgrund von Reihenfolgeprobleme (falsche Sortierung) verstümmelte Nachrichten ergeben. Es empfiehlt sich also für den Nutzer zu dieser Zeit keine kritische Kommunikation durchzuführen. Anders sieht es bei Internetapplikationen aus. Erstens leben Anwendungen in der Regel länger als die zugrundeliegenden technischen Systeme und zudem sind sie wegen unzureichender Standardisierung nicht so leicht auszuwechseln oder reparieren wie die Hardware.

Die Verwendung zweistelliger Jahreszahlen unterstellt, dass das Jahrhundert gleich 19 ist. Dies stimmt 2000 natürlich nicht mehr. Durch das programmgesteuerte Setzen des Jahrhunderts, können auch vierstellige Jahreszahlen betroffen sein.

Des weiteren kann es vorkommen, dass die Jahreszahlen 99 und 00 als herausgehobene Werte interpretiert werden. Wir müssen also darauf gefaßt sein, dass dieses Problem tatsächlich bereits vor dem 1. Januar 2000 auftritt.

Die folgenden Fehler und Fehlverhalten der Anwendungen sind durch falsch interpretierte Datumsfelder sind zu erwarten:

• Die zweistellige Jahreszahl wird zu Vergleichs-, Sortier- und Rechenfehler führen (00 ist kleiner als 99).
• Viele Schaltjahralgorithmen werden das Jahr 2000 nicht als Schaltjahr erkennen (es ist durch 400 teilbar) und somit keinen 29. Februar ausweisen.
• Dort wo das Jahrhundert mit 19 fest vorgegeben ist, kommt es zu den gleichen Problemen wie mit zweistelliger Zahlenangabe.
• Bei Assemblerprogrammen und anderen Betriebssystemnahen Programmiersprachen, kann es zu Registerüberläufen oder Allokierungsfehlern kommen.
• Alte Systemroutinen werden falsche Datumsangaben liefern.

Wie Harry M. Sneed jüngst in seinem Newsletter schreibt, ist das Datumsproblem nicht neu. Bereits Ende 1969 sind alle IBM-360 Rechner in Europa abgeschaltet worden, weil sie über das Jahr 1969 nicht hinwegkommen konnten. Das heutige Problem ist von der gleichen Art, aber durch die gestiegene Quantität und Komplexität der Anwendungen ungleich größer.

Um diese Fehler zu vermeiden bzw. zu beheben muss in die Anwendungen eingegriffen werden. Nach Robert Martin von der MITRE-Corporation gibt es die folgenden Ansätze zur Lösung des Datumswechsels:

• Erweiterung des Datumsformates von 6 (tt.mm.jj) auf 8 Stellen (tt.mm.jjjj).
  Dies dürfte die sauberste Lösung sein, enthält aber auch die größten Auswirkungen, weil alle Programme und Datenbestände angefaßt werden müssen.
• Verpackungs des Datums in 6 oder 4 Bytes (Neojulian).
  Hierbei werden die bestehenden Datenelemente dazu genutzt, das Datum in anderer Form zu speichern. Es müßte vor der Präsentation allerdings umgesetzt werden. Dies erfordert zudem die Überarbeitung aller bisher gespeicherten Daten.
• Verwendung eines Zeitfensters.
  Beispielsweise 50 bis 99 entspricht 19JJ, 00 bis 49 ist 20JJ. Wenn das Zeitfenster größer als 100 Jahre sein muss funktioniert dies allerdings nicht mehr.
• Benutzung von Datumskonvertierungsroutinen (Bridging Technik).
  Es handelt sich dabei um Standardroutinen, zumeist nach Zeitfenster-Prinzip, die zwischen Datenhaltung und Anwendungsprogramme oder Benutzerschnittstelle und Programm geschaltet werden und das Datum umsetzen.
• Rückstellung der Systemuhr mit einer 28-jährigen Zeitbrücke.
  Das dargestelltes Datum entspricht dann dem Systemdatum plus 28 Jahre. Dies ist wohl die einzige Lösung, falls der Sourcecode einer Anwendung nicht mehr änderbar/vorhanden ist. 28 Jahre deshalb, weil dann die Tage und Wochen dem jeweils aktuellen Jahr entsprechen.
• Ablösung der Software.
  Wahrscheinlich der Königsweg, aber nur selten machbar, da hierfür Geld und Kapazitäten vorhanden sein müssen. Außerdem werden Fachbereiche nur dann mitziehen, wenn die vorhandene Lösung ohnehin nicht erhaltenswert ist.
• Nichts.
  Dies läßt sich sicherlich machen, wenn die Auswirkungen des Jahrtausendwechsels nicht so gravierend sind und vom Anwender hingenommen bzw. ausgeglichen werden. Dies muss als Übergangslösung in Betracht gezogen werden, wenn eine baldige Ablösung vorgesehen ist.

Keine Lösung ist sicherlich in manchen Fällen auch eine Lösung. Bevor aber eine Lösung auch angegangen werden kann, muss klar sein, welchen Umfang das Problem in den Anwendungen hat und welche Auswirkungen durch fehlerhafte Datumsbehandlungen der einzelnen Anwendungen in den Fachbereichen entstehen.

Zunächst muss untersucht werden, wie groß das Umstellungsproblem für das Unternehmen überhaupt ist und für welche Anwendungen auch ein Umstellungsbedarf existiert. Anwendungen, die rechtzeitig durch neue ersetzt werden bedürfen keiner Umstellung, aber auch für die verbleibenden ist der jeweilige Umstellungsbedarf erst durch eine Untersuchung der Datenbestände und Programme zu erkennen.

Im ersten Schritt sind alle Anwendungen aufzunehmen und es muss festgestellt werden, ob sie im gegebenen Zeitrahmen überhaupt relevant sind, d.h. sie werden über das Jahr 2000 hinaus genutzt. Da die Bearbeitung der Anwendungen viel Aufwand verbunden ist, müssen die Kräfte konzentriert werden und es müssen gegebenenfalls Werkzeuge oder zusätzliches Personal zur Verstärkung eingekauft werden. Daher muss auf die Analyse der Anwendungen die Planung der Umstellung folgen.

Literatur:

Knolmeyer 97

Gerhard Knolmeyer; Das Jahr 2000 Problem: Medien-Spektakel oder Gefährdung der Funktionsfähigkeit des Wirtschaftssystem?; in Wirtschaftsinformatik Bd. 39 (Wiesbaden: Gabler, 1997) S. 7 - 18.

Sneed 97

Harry M. Sneed; Das ewige Problem mit der Zeit; in Software Engineering Newsletter, Heft 47 (München: SES, 1997) S. 7ff.