Der Y2K22-32-Bit-Bug
Herrje, ist das alles wieder schlimm.
Zum Jahr 2000 gab es ja schon das große Zähneklappern. Die Firma, bei der ich damals war, hatte zur Silvesternacht volle Präsenz und Bereitschaft befohlen und deshalb eine – alkoholfreie – Silvesterfeier veranstaltet, damit die Leute auch alle da waren und ein bisschen feiern und sogar die Familie mitbringen konnten. So bis etwa 5 Minuten nach Mitternacht durfte gefeiert werden, dann hieß es: An die Rechner. Komplett, alles auf Funktion prüfen.
Sämtliche eigenen und Kunden-Systeme bis zum Morgengrauen durchgecheckt und auf Funktion geprüft. Der Brüller: Ausnahmslos alle Kunden und deren IT- und Rechenzentrumsbesatzungen waren auch in deren Betrieben und im Einsatz, und während draußen die Raketen flogen, wurden die Systeme durchgeprüft wie noch nie zuvor. Ergebnis: Kein einziger Jahr-2000-Bug. Lief alles einwandfrei. Weil genug Panik und Tests im Vorfeld, die alle Problem schon gefunden hatten.
Ein Bug im Microsoft Exchange-Server sorgt seit dem 1. Januar 2022 dafür, dass keine E-Mails mehr zugestellt werden können. […]
Der Jahr-2022-Bug hat beim Microsoft-Exchange-Server zugeschlagen. Der Virenscanner FIP-FS Scan Engine meldet einen Fehler mit dem Text “Can’t Convert ‘2201010001’ to long”. Der Mailserver stellt daraufhin die Zustellung von E-Mails ein. […]
Der Sicherheitsforscher und Exchange-Administrator Joseph Roosen teilte über Twitter mit, dass Microsoft eine int32-Variable mit Vorzeichen verwendet, um den Wert eines Datums zu speichern, die einen maximalen Wert von 2.147.483.647 hat. Datumsangaben im Jahr 2022 haben jedoch einen Mindestwert von 2.201.010.001.
Mal abgesehen davon, dass es ein völlig beklopptes Format ist, Datum und Uhrzeit 1.1.2022 00:01 als 2.201.010.001 zu speichern (Linux speichert das in fortlaufenden Sekunden seit dem 1.1.1970, womit wir gerade bei 1.641.152.153 sind, bis 232, oder genauer gesagt, wegen des Vorzeichens im obersten Bit, bis 231-1, also noch einiges Zeit wäre, hat man unter Linux die Zeitangaben längst in 64 Bit umgestellt, auch weil man sie oft in Millisekunden ausdrückt – Dateisysteme brauchen das heute so, weil die Rechner so schnell sind, dass man Dateiabhängigkeiten für Tools wie Make u.ä. mit Sekundengranularität nicht mehr abbilden kann.)
Selbst wenn man unbedingt so doof sein wollte, Uhrzeit und Datum nach Minute, Stunde, Tag, Monat und Jahr in einer 32-Bit-Zahl speichern zu wollen (wovon ich abrate), wäre es immer noch dämlich, das mit der Dezimaldarstellung zu mischen. Da würde man eher 6 Bit für die Minute, 6 Bit für die Stunde (jeweils 0..63), 5 Bit für den Tag (0..31), 4 Bit für den Monat (0..15) verwenden und noch irgendwas (6 Bit) für Jahr ab X. Zusammen 27 Bit. Ist aber trotzdem lausig.
Diese Form der Codierung würde ich als Programmiertechnik einstufen, die ich vom Stil her so in den 80er oder frühen 90er Jahren sehen würde, als man für Disketten und sowas noch mit jedem Bit knapsen musste und sowas wie 32-Bit-Divisionen zu vermeiden suchte.
Wenn man schon so einen Schrott treibt, dann sollte man wenigstens ein paar Test-Systeme mit Datum in der Zukunft laufen lassen, damit man von sowas nicht ausgerechnet am Neujahrswochenende überrascht wird.