17 014 118 …

Die Unixzeit zählt die vergangenen Sekunden seit dem 01. Januar 1970, 00:00 Uhr UTC, wobei Schaltsekunden nicht mitgezählt werden. Alles, was vor 1970 Stattfand, ist nicht so ohne Weiteres in Unixzeit auszudrücken. Man müsste dann mit negativen Werten rechnen (was im POSIX-Standard des Zeitstempels durchaus vorgesehen ist), oder den Startzeitpunkt programmintern anders definieren, und jeden Wert entsprechend umrechnen.

Das Zeitschema vieler veralteter Betriebssysteme reicht von 1980 bis 2099. Mit dem Jahreswechsel auf 2000 sprangen jedoch viele dieser Computer nicht von 1999 zu 2000, sondern auf das Anfangsdatum 1. Januar 1980 um. Allerdings war dies weniger Problematisch, da es reichte, das Datum einfach neu einzugeben.

Im Jahre 1999, genauer gesagt, der 9. September 1999 (sehr kurz nach DIN: 9.9.99): Möglicherweise könnten Programmierer dieses Datum (bzw. die Zeichenfolge) als Endekennzeichnung für Dateien oder Datensätze in einem Stream verwendet haben. Allerdings gab es auch schon damals andere und bessere Methoden, das Dateiende zu bestimmen, daher wurde das Problem meist nicht weiter beachtet. Zumal auch nichts diesbezüglich bekannt wurde.

Angesichts des Jahreswechsel 1999/2000 wurde das Problem offenbar, dass mit der zweistelligen Jahreszahl "00" sowohl das Jahr 1900 als auch das Jahr 2000 bezeichnet werden kann. Schon hatte man ein Problem, wenn man das Datum intern nur zweistellig angab. Es macht eben doch einen Unterschied, ob jemand 1900 geboren wurde, oder 2000.

Auch war es üblich, dort, wo Datumsangaben gemacht werden mussten, aber entsprechende Daten nicht vorlagen, „00“ als „nichts“ einzugeben. Mit dem Jahre 2000 war dies nun aber plötzlich eingültiger Wert.

Jedes vierte Jahr ist ein Schaltjahr. Das Jahr jedes vollen Jahrhunderts ist aber kein Schaltjahr. Diese Regelung findet allerdings alle 400 Jahre nicht statt. Vor diesem Hintergrund ergab sich, dass das Jahr 2000 Schaltjahr war, das Jahr 1900 jedoch nicht. Es hätte also durchaus vorkommen können, wenn ein Programmierer es nicht berücksichtigt hätte, dass das System plötzlich nicht nur ein Jahrhundert nachgeht, sondern auch noch einen Tag vorgeht.

Laut mehreren Aussagen der Experten, wird der IPv4-Block im Jahre 2011 zu Ende gehen. Es werden dann also alle öffentlich verfügbaren IPs vergeben sein, und es werden die Leute keine Onlineverbindung mehr haben, weil sie keine IP bekommen. Dem kann laut der Experten nur vorgebeugt werden, indem auf IPv6 umgestiegen wird.

Im Jahre 2038 kann es zu Systemausfällen kommen, da der 32-Bit-Zeitstempel nach dem POSIX-Standard am 19. Januar 2038 um 03:14:08 Uhr UTC die Kapazität einer 31-Bit-Zahl überschreiten wird. Das 32. Bit wird laut der Definition dazu verwendet, positive und negative Zahlen zu unterscheiden.

Ohne Problembehebungsmaßnahmen wird es zu Fehlern bei elektronischen Transaktionen, die die Unixzeit als Zeitstempel verwenden, kommen. Die wirtschaftlichen Auswirkungen können verheerend sein, zumal im Banken- und Versicherungsumfeld Unix-Systeme neben Mainframes zur Standardausstattung gehören.

Der Jahreswechsel 9999/10000 wird ebenfalls ein Problem hervorrufen können, und war wird dann das Jahr von vierstellig auf fünfstellig wechseln. Je nach dem, wo dann abgeschnitten wird, haben wir entweder das Jahr Null (0000 = 0), oder das Jahr 1000. Problematisch wird es auf jeden Fall …

Wenn alle Unix-Zeitstempel-Verwendenden Programme auf einen 64-Bit-Zeitstempel umgestellt werden – was wahrscheinlich ist – dann wird der nächste Unix-Timestamp-Bezogene Systemausfall am Sontag, dem 4. Dezember im Jahre 292 277 026 596 stattfinden.

Vorausgesetzt, die Technik entwickelt sich so weiter, wie bisher, dann wird es irgendwann dazu kommen, dass wir 128-Bit-Systeme verwenden. Wenn man dann die Programme dahingehend umstellen würde, dass ein 128 Bit langer Timestamp verwendet wird, dann wäre das nächste Zeitstempel-Problem erst weit nach Ende unseres Sonnensystems von Bedeutung.

Nämlich am 31. Dezember im Jahre 17 014 118 346 046 923 173 168 730 371 588 410 …