Software::UNIX
Unix-Zeitzähler erreicht 1500000000
Seit heute morgen sind die ersten beiden Ziffern der Unix-Zeit 15 statt 14. Damit sind nun mehr als eineinhalb Milliarden Sekunden seit dem 1.1.1970 vergangen. Bis zum Überlauf des Zählers bleiben noch eine halbe Milliarde Sekunden, rund 20 Jahre und 6 Monate. Doch Maßnahmen gegen die Probleme, die daraus entstehen können, müssen bereits jetzt ergriffen werden.
gnome.org
Nur wenige Menschen werden wach geblieben sein, um heute Nacht genau um 4:40 Uhr MESZ den Unix-Zeitzähler von 1499999999 auf 1500000000 umspringen zu sehen. Im Grunde hat das Ereignis auch genauso viel Bedeutung, wie wenn ein Kilometerzähler von 9999 auf 10000 wechselt. Doch ist es eine Gelegenheit, wieder einmal daran zu denken, dass der Unix-Zeitzähler überlaufen wird - und wie kompliziert es ist, Abhilfe zu schaffen.
Diese Unix-Sekundenzählung berücksichtigt nicht die Schaltsekunden, die im Lauf der Jahre eingelegt wurden. Die reale Zeit seit dem 1.1.1970 0:00 Uhr, was als Beginn des Unix-Zeitzählers festgelegt wurde, ist daher um einige Sekunden größer, allerdings wird diese Differenz von keiner Uhr berücksichtigt. Somit sind Unix-Systeme hier im Einklang mit dem Rest der Welt.
Selten im Einklang mit der Realität sind Computer dagegen, wenn es um das große Ganze geht. So auch beim Datum. Da Speicher in Computern historisch knapp und teuer war, wurde der Zeitzähler als 32-Bit-Zahl definiert - mit Vorzeichen, um auch Zeiten vor 1970 darstellen zu können. Daher wird im Jahr 2038 zwangsläufig ein Überlauf eintreten. Im Betriebssystem-Kernel (Linux, BSD) kann dies leicht durch eine Verlängerung auf 64 Bit behoben werden. Doch der Wert wird auch durch verschiedene Kernel-Schnittstellen und Systemaufrufe an die Anwendungen übergeben. Damit besteht das Problem in allen 32 Bit-Systemen und 32 Bit-Anwendungen. Das Problem ist seit langem bekannt und es wurden bereits Änderungen diskutiert oder vorgenommen, um es zu lösen.
In dieser Beziehung sind NetBSD und OpenBSD bereits weiter, allerdings begünstigt durch die Tatsache, dass deren Ökosystem kleiner ist. Für ältere, nur als Binärdateien vorliegende Programme wurde ein Kompatibilitätsmodul geschaffen. Die entsprechenden Änderungen wurden bereits im Oktober 2012 in NetBSD 6.0 sowie in OpenBSD 5.5 im Oktober 2014 publiziert. Die Änderung bestand in der Erweiterung des Unix-Zeitzählers, repräsentiert durch den Datentyp time_t, auf 64 Bit für alle Architekturen, also auch die 32-Bitter. Alle Programme in diesen Betriebssystemen und den Ports-Sammlungen mussten angepasst, neu compiliert und getestet werden, um das zu erreichen.
Auch in Linux wird eine Lösung angestrebt, die die Kompatibilität mit bestehenden Anwendungen, die 32-Bit-Zeit verwenden, soll auf allen Architekturen wahrt. In den letzten Jahren wurde klar, dass dazu auch eine enge Zusammenarbeit zwischen den Kernel-Entwicklern und denen von glibc nötig ist. Denn der Kernel kann zwar neue Systemaufrufe mit 64-Bit-Zeit zur Verfügung stellen, aber es ist Sache der glibc, diese in POSIX-kompatiblen Funktionen den Programmen zugänglich zu machen. Seit Februar 2017 liegt ein Entwurf zu den nötigen Änderungen in glibc vor, der im April und Juni nochmals aktualisiert wurde. Die Implementation wurde inzwischen begonnen und kann auf Github verfolgt werden.
Der Entwurf versucht alle Aspekte der geplanten Umstellung abzudecken und ist daher sehr ausführlich. Er definiert zunächst den Bereich, für den er zuständig ist, die grundlegenden Begriffe, die zu erreichenden Ziele und die Randbedingungen. Dann werden die von glibc definierten Datentypen und Funktionen ausführlich analysiert. Es folgen die geplanten Änderungen an Datentypen und Funktionen und Kompatibilitätsbetrachtungen.
Laut diesem Entwurf werden die bisherigen Zeitfunktionen unverändert bleiben und sich auf 32-Bit-Zeitstempel beziehen. 64-Bit-Zeitfunktionen werden neu hinzukommen. Programme werden entweder die 32-Bit-Zeitfunktionen oder deren 64-Bit-Äquivalent nutzen können, aber nicht beide. In den nächsten Jahren werden die 32-Bit-Varianten noch die Voreinstellung sein, so dass sich für die Anwendungen zunächst nichts ändert. Verlangt eine Anwendung explizit die 64-Bit-Zeit, werden die Datentypen und Funktionen entsprechend umdefiniert, behalten aber ihre Namen. Sauber geschriebene Anwendungen sollten, zumindest solange sie keine Zeiten nach 2037 verwenden, unverändert funktionieren, gleichgültig, ob sie mit 32- oder 64-Bit-Funktionen compiliert wurden.
){kind=small}
