Haben Sie am Dienstagabend auch die Sekunden runtergezählt, um auf die runden 1.700.000.000 anzustoßen? In einigen Hackerspaces wurde dieser besondere Unix-Zeitstempel wie bei einer Neujahrsfeier begrüßt. Für die Darstellung von Daten und Uhrzeiten als Binärzahl gibt es viele Konventionen. Sehr weit verbreitet ist der für das Unix-Betriebssystem entwickelte Ansatz, einen Zeitpunkt über die Anzahl von Sekunden seit dem 01.01.1970 darzustellen. Diese Sekundenzahl überschritt am Dienstagabend die nächste 100-Millionen-Marke. Falls Sie das Ereignis verpasst haben: Merken Sie sich schon einmal den 15.01.2027 vor – da sind die nächsten 100 Millionen Sekunden vorbei.
Bei der Darstellung von Daten kommt unweigerlich die Erinnerung an das Jahr-2000-Problem auf. Tatsächlich wird bei den Unix-Zeitstempeln im Jahr 2038 Ähnliches passieren. Wie beim Jahr-2000-Problem hängt dies aber von einigen Details ab: Waren damals nur Anwendungen und Systeme betroffen, die Jahreszahlen als zweistellige Dezimalzahl gespeichert haben, sind es jetzt Zeitstempel, die als 32-Bit-Zahl mit Vorzeichen gespeichert sind. Das ist die Mindestgröße, die der Standard vorschreibt, und traditionell wurden die Zeitstempel in einem Speicherformat entsprechend der Länge eines „Word“ beim verwendeten Prozessor gespeichert – also 32 Bit auf 32-Bit-CPUs und 64 Bit auf 64-Bit-CPUs. Damit sind moderne Client- und Serversysteme nicht mehr betroffen. In vielen eingebetteten Systemen werden jedoch weiterhin viele 32-Bit-CPUs eingesetzt. Diverse Betriebssysteme und Anwendungen mit Unix-Zeitstempel haben bereits reagiert und nutzen auch auf diesen Systemen die längeren Speicherformate. Schwierig ist die Umstellung bei Binärdateiformaten und Netzwerkprotokollen, die nur 32 Bit Platz für die Zeitstempel vorsehen. Ob die Darstellung überall angepasst wurde, zeigt der 19.01.2038 – an diesem Datum wird der größtmögliche 32-Bit-Zeitstempel überschritten.
Die nächsten runden Termine zum Vormerken: https://de.wikipedia.org/wiki/Unixzeit#Besondere_Werte
Die Jahre 2000 und 2038 sind nicht die einzigen interessanten Zeitpunkte:
https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs