Im Jahr 2000 kam und ging der Jahr-2000-Fehler ohne große Probleme. Trotz der Vorhersagen eines weit verbreiteten Ausfalls wurde die Krise sowohl durch langfristige als auch durch kurzfristige Planung und Intervention abgewendet, und keine kritischen Systeme fielen aus. In den folgenden Jahren wurden die wenigen betroffenen Betriebssysteme und Anwendungen in den meisten Fällen aktualisiert, ersetzt oder außer Betrieb genommen.
Wenn Sie ein Unix- oder Linux-basiertes System verwenden, müssen Sie sich um einen weiteren datumsbezogenen Fehler kümmern – im Jahr 2038.
Alle 32-Bit Unix/Linux-basierten Systeme speichern die Systemuhrzeit intern als die Anzahl der Sekunden seit der Epoche, oder 00:00:00 am 1. Januar 1970. Dieser interne Datentyp, time_t, ist in den meisten Fällen eine 32-Bit (4-Byte) Ganzzahl mit Vorzeichen. Wenn das betreffende System dem POSIX-Standard folgt (wie die meisten Unix- und Linux-Systeme), ist die späteste Zeit und das späteste Datum, die als Sekunden seit der Epoche in dieser 32-Bit-Ganzzahl mit Vorzeichen dargestellt werden können, 3:14:07 UTC am Dienstag, dem 19. Januar 2038.
Nach dieser Zeit und diesem Datum erreicht die interne Darstellung der Systemzeit 2147483647, die höchste Zahl, die in einer 32-Bit-Ganzzahl mit Vorzeichen gespeichert werden kann. Eine Sekunde danach erreicht sie eine negative Zahl, -2147483648. Aktuelle Anwendungen interpretieren diese negative Zahl entweder als ein älteres Jahr (1901) oder frieren die Systemuhr bei 03:14:07 am 19.1.2038 ein. Dies kann dazu führen, dass Anwendungen und Betriebssysteme versagen, da sie nicht dafür ausgelegt sind, mit einer hängenden Systemuhr oder einer Uhr, die das Jahr 1901 anzeigt, zu arbeiten.
Es gibt keine praktikablen Lösungen (die bestehende Anwendungen nicht zerstören) für Systeme mit 32-Bit-Prozessoren oder Betriebssysteme und Anwendungen, die im 32-Bit-Modus auf 64-Bit-Prozessoren laufen. Viele aktuelle Unix/Linux-Betriebssysteme laufen bereits im 64-Bit-Modus (mit einer entsprechenden „langen“ time_t, wenn sie auf einem 64-Bit-Prozessor laufen; in den meisten Fällen löst dies das Problem.
Betriebssysteme, die eine lange 64-Bit time_t unterstützen, sind höchstwahrscheinlich nicht vom Jahr-2038-Bug in Bezug auf die interne Systemuhr betroffen. Allerdings können Anwendungen, die eine 32-Bit time_t verwenden, immer noch fehlschlagen, selbst wenn das System, auf dem die Anwendung läuft, den vollen 64-Bit-Betrieb unterstützt.
Hier ist ein kurzer Überblick über den aktuellen Status der Unix 2038-Unterstützung in den gängigen Unix/Linux-Versionen:
- Solaris 7 oder höher auf 64-Bit-UltraSPARC- und SPARC64-Prozessoren sowie Solaris 10 auf x86-64-Plattformen hat eine 64-Bit time_t.
- AIX Version 4.3.3 auf 64-Bit PowerPC- und Power-Prozessoren hat eine 64-Bit time_t.
- Der Linux-Kernel, der im 64-Bit-Modus auf IA64- oder x86-64-Prozessoren läuft, hat eine 64-Bit time_t.
- Mac OS X Version 10.4 und neuer hat einen 32-Bit-Kernel, aber Anwendungen können eine 64-Bit time_t verwenden, wenn sie auf PowerPC G5 oder x86-64 CPUs laufen.
- FreeBSD 6.0 und höher hat eine 64-Bit time_t, wenn es auf einer 64-Bit-Plattform läuft.
- OpenBSD 4.1 und neuer unterstützen eine 64-Bit time_t.
- NetBSD hat noch keine 64-Bit time_t, aber es wird daran gearbeitet, das Problem in einer kommenden Version zu beheben.
Auch wenn Ihr aktuelles Betriebssystem noch nicht Unix 2038 sicher ist, machen Sie sich keine Sorgen! Das Problem ist seit vielen Jahren bekannt, und es wird aktiv an Lösungen gearbeitet. In den meisten Fällen wird das Problem dadurch gelöst, dass das Betriebssystem und die Anwendungen schließlich im vollständigen 64-Bit-Modus laufen.
Ich erwarte, dass alle wichtigen Desktop-Betriebssysteme in den nächsten fünf bis zehn Jahren vollständig 64-Bit-fähig sein werden. Außerdem wird ein Durchsickereffekt dazu beitragen, dass aktuelle Systeme durch 64-Bit-Konfigurationen ersetzt werden, wo dies sinnvoll und kostengünstig ist.
ÜBER DEN AUTOR: Bill Bradford ist der Erfinder und Betreuer von SunHELP und lebt mit seiner Frau Amy in Houston, Texas.