Erinnerung an das Jahr-2038-Problem
Die Businessworld erinnert in einem Artikel daran, daß im Jahr 2038 ein Zahlenüberlauf in der UNIX/Linux-Zeitzählung auftritt, der zu möglichen Fehlfunktionen führen kann.
Das Problem ist schon lange bekannt, eine allgemeine Lösung ist aber noch nicht definiert worden, obwohl sich mögliche Lösungen bereits abzeichnen. Warum es von der Businessworld gerade jetzt als ein Problem vom Range des Jahr-2000-Problems dargestellt wird, ist nicht nachzuvollziehen. Auch wird nicht erwähnt, daß es auf Windows-Systemen genauso existiert und die gleichen Konsequenzen hat.
Seinen Ursprung nimmt das Problem in der Funktion time() der Standardbibliothek der Programmiersprache C. Diese liefert eine 32-Bit-Zahl, die die Zahl der Sekunden seit dem 1.1.1970 angibt. Das oberste Bit dieser Zahl wird üblicherweise als Vorzeichenbit behandelt, was zu dem erwähnten Überlauf im Jahr 2038 führt, da die Zahl dann vom Maximum 2147483647 auf das Minimum -2147483648 umspringen wird. Betroffen davon sind einige C-Programme, darunter möglicherweise auch einige Systemtools, sowie alle Skripte, die diese verwenden und alle Programme, die indirekt die C-Bibliothek verwenden. Alle diese müssen irgendwann geprüft werden, doch sind dafür noch fast 33 Jahre Zeit.
Programme, die heute bereits einen größeren Datumsbereich benötigen, als time() liefern kann, oder eine zeitliche Auflösung unterhalb einer Sekunde, benutzen jetzt schon andere Datentypen und sind damit nicht anfällig für das Problem. Der Artikel der Businessworld unterstellt dagegen, daß die Autoren der Programme nicht schlau genug waren, dies vorauszusehen. Auch im Bereich der eingebetteten Systeme sieht er Probleme heraufziehen, da dort die Systeme nicht so häufig ausgetauscht werden. Doch eine Lebensdauer von dreißig Jahren dürfte auch dort eine Ausnahme sein.
Recht hat Businessworld damit, daß es eine Änderung in der C-Bibliothek geben muß, und diese sollte bald angegangen werden. Eine zusätzliche Funktion time64() beispielsweise, die allmählich time() ablöst, würde durch Verwendung einer 64-Bit-Zahl das Problem ein für allemal lösen, da das Ende des Universums sehr viel früher käme als ein Überlauf dieses Zählers. Diese Änderung ist unabhängig davon, ob es im Jahr 2038 noch 32-Bit-Computer gibt - und sollten die Computer bis dahin völlig anders funktionieren oder die Sprache C ausgestorben sein, dann wäre das Problem sowieso erledigt.
Allerdings wären auch andere Lösungen denkbar. So könnte man sich fragen, ob eine einfache Sekundenzählung überhaupt noch sinnvoll ist. Wie rechnet man beispielsweise die Schaltsekunden ein, die alle 1-2 Jahre notwendig sind? Da Schaltsekunden aber auch andere Probleme verursachen und im Jahr 2006 eventuell über eine Neuregelung entschieden wird, braucht man sich bis dahin wohl keine Gedanken über eine neue Zeitfunktion zu machen.
Sollte die interne Zeitmessung des Linux-Kernels derzeit noch von dem Problem betroffen sein, so läßt sich dies leicht beheben, ohne daß eine einzige Applikation geändert werden muß. Denn die Kernel-Zeitmessung kann völlig unabhängig von dem sein, was die Applikationen über gettimeofday(), den Systemaufruf hinter time(), als Zeit erhalten. Allerdings muß ein neuer Systemaufruf geschaffen werden, der gettimeofday() allmählich ablöst.
