Vor 21 Jahren machte sich Apple über den Jahr-2000-Bug in PCs lustig, der zum Jahreswechsel auf das Jahr 2000 eine globale Wirtschaftskrise auslösen sollte. Nur der Macintosh sei sicher und so programmiert, dass er zu Beginn des neuen Milleniums nicht ausfallen werde. Das zumindest war eine Werbeaussage von Apple im Rahmen des Superbowls 1999. Im Rückblick wissen wir es besser. Die vorhergesehenen Ereignisse sind nicht eingetreten. Und was sollte nicht alles passieren: Flugzeuge, die vom Himmel fallen; Banken, die kein Geld mehr auszahlen können; Firmen, die pleite gehen, weil sie den 1. Januar 2000 nicht vom 1. Januar 1900 unterscheiden und somit 100 Jahre zurückgeworfen werden.
Mehr Apple-Wissen für dich.
Mac Life+ ist die digitale Abo-Flatrate mit exklusiven, unabhängigen Tests, Tipps und Ratgebern für alle Apple-Anwenderinnen und Anwender - ganz egal ob neu mit dabei oder Profi!
Mac Life+ beinhaltet
- Zugriff auf alle Online-Inhalte von Mac Life+
- alle digitalen Ausgaben der Mac Life, unserer Sonderhefte und Fachbücher im Zugriff
- exklusive Tests, Artikel und Hintergründe vorab lesen
- maclife.de ohne Werbebanner lesen
- Satte Rabatte: Mac, iPhone und iPad sowie Zubehör bis zu 15 Prozent günstiger kaufen!
✔ SOFORT gratis und ohne Risiko testen: Der erste Monat ist kostenlos, danach nur 4,99 Euro/Monat.
✔ Im Jahresabo noch günstiger! Wenn du direkt für ein ganzes Jahr abonnierst, bezahlst du sogar nur 2,99 Euro pro Monat.
Das alles wäre passiert, wenn in der Informationstechnik Jahreszahlen und Datumsberechnungen tatsächlich mit den letzten beiden Stellen des Jahres ausgeführt worden wären. Doch vor dem Jahr 2000 wurden fleißig Betriebssysteme aktualisiert, in den Banken die Excel-Makros angepasst und vieles mehr. Denn der Jahr-2000-Bug ist gar kein Computer-Bug sondern genau genommen lediglich ein Software-Bug, der rechtzeitig erkannt und isoliert wurde. Der Macintosh hatte vor Mac OS X seinen Datumsnullpunkt am 1. Januar 1904 und war quasi von Haus aus gegen den Y2K-Bug immunisiert. Seit OS X berechnet das Betriebssystem das Datum beginnend am 1. Januar 1970, wie es alle Unix-basierten Systeme machen. Doch gerade dieser Trick kann nun im Jahr 2038 zum Problem werden, und zwar genau am 19. Januar 2038 um 3 Uhr 14 Minuten und 7 Sekunden.
Y2K38-Problem: Am 19. Januar 2038 ist der 32-Bit-Adressraum erschöpft
Um das Y2K38-Problem zu verstehen, muss man wissen, wie Computer mit Zahlen rechnen. Computer rechnen binär in Nullen und Einsen. Und dann gibt es die Konvention, negative Binärzahlen mit einer führenden 1 zu kennzeichnen. In den frühen Morgenstunden des 19. Januar in 18 Jahren ist der Zahlenraum aufgebraucht, sofern es sich um ein 32-Bit-System handelt. Denn seit dem 1. Januar 1970 sind 2.147.483.647 Sekunden vergangen, die als vorzeichenbehaftete 32-Bit-Ganzzahl dargestellt werden als 31 Einsen mit einer führenden Null: 01111111111111111111111111111111. In der nächsten Sekunde nach dem 19. Januar 2038 um 3 Uhr 14 Minuten und 7 Sekunden springt der Binärzähler um auf eine führende 1 mit 31 Nullen und der Computer berechnet dann das Datum als negative Zahl 2.147.483.648 Sekunden vor dem 1. Januar 1970. Das wäre dann Abends um Viertel vor Neun am 13. Dezember 1901 – eine Zeitreise wider Willen!
Was wird passieren?
Welche Computer-Systeme in rund 18 Jahren Probleme bekommen werden, kann man nicht genau vorhersagen. Einige laufen mit dem falschen Datum weiter, andere könnten einfach stoppen. Das Schreckensszenario des Y2K-Bugs mit abstürzenden Flugzeugen wird sicherlich nicht eintreten, da die meisten Computer längst durch 64-Bit-Hardware ersetzt sein dürften. Auf dem Mac etwa wird mit macOS Catalina (v10.15) keine 32-Bit-Software mehr ausgeführt. Aber andere Unix-Systeme – auch die, die 32-Bit-Software auf 64-Bit-Hardware ausführen – könnten Probleme bekommen, wenn die Datumsberechnung zu fehlerhaften Zeiteinstellungen führt. Problematisch dürften eingebaute Schaltkreise werden, die in irgendwelchen vergessenen Maschinen stecken. Das können etwa Relais in Pumpen sein, die sich nicht mehr einschalten lassen, weil das letzte Wartungsintervall plötzlich nicht mehr ein Jahr zurück liegt, sondern 135 Jahre in der Zukunft und noch gar nicht stattgefunden haben kann.
Kleine und großen Katastrophen
Datumsbasierte Probleme tauchen immer mal wieder auf. So könnte die Hamburger Hochbahn ihre neuen Züge der Baureihe DT5 von Alstom-Bombardier nach dem 1. Januar 2020 nicht nutzen, weil – wie der Sender NDR 90,3 berichtet – der Bordcomputer das Jahr 2020 nicht kannte und dann nicht startete. Und der Fairness halber muss man einräumen, dass auch Apple in der Vergangenheit immer mal wieder Datum-basierte Probleme hatte. Man denke etwa an verstellte Wecker durch den automatischen Wechsel auf die Sommerzeit am iPhone in früheren iOS-Versionen.
Aber im Gegensatz zum Y2K-Bug, der sich als nicht relevant erwies, kann das eigentlich nicht relevant erscheinende Y2K38-Problem sehr wohl zu Schwierigkeiten führen. Nämlich dann, wenn altgediente Software in ansonsten zuverlässiger Hardware plötzlich Probleme macht. Noch aber haben wir Zeit, uns auf das Y2K38-Problem vorzubereiten.
Diskutiere mit!
Hier kannst du den Artikel "Y2K38: Das Jahr-2038-Problem" kommentieren. Melde dich einfach mit deinem maclife.de-Account an oder fülle die unten stehenden Felder aus.
In 18 Jahren spielt das keine Rolle mehr.
Das mag sein, aber das Y2K38-Problem ist ein aktuelles Problem. Programme, die zwanzig Jahre in die Zukunft rechnen, steigen am 19. Januar 2038 aus, liefern keine validen Ergebnisse mehr, wie ein Entwickler auf Twitter ( j.mp/37iIcaK ) schildert. Dort am Beispiel von Pensionsfonds.
ich stelle dann bei meinen noch aktiven 32 Bittern einfach das Datum 100 Jahre zurück. Dann laufen die noch ein Weilchen länger.
Unter Linux x64 ist der Y2K38 schon längst gefixt und für Linux 32-Bit wird dies mit Version 5.6 gelöst sein.
Nur soviel zu "Auf dem Mac etwa wird mit macOS Catalina (v10.15) keine 32-Bit-Software mehr ausgeführt."
Das ist wieder ein Beispiel für Ignoranz und Dummheit, wie Apple Probleme löst.