Der Unix Timestamp wächst nicht linear
Published 13 August, 2013Was genau ist die Unixzeit? Meistens wird einfach gesagt: Die Anzahl der Sekunden seit 00:00 Uhr am 1. Januar 1970. Das ist jedoch falsch.
Ein kurzer Crashkurs über die Zeit
Bis 1967 wurde die Länge einer Sekunde astronomisch bestimmt. Das war soweit auch ganz gut, weil wir Menschen uns ebenfalls nach der astronomischen Zeit richten (wenn es dunkel wird, gehen wir schlafen). Das ist allerdings nicht sehr genau, da die Länge eines Tages/Jahres leicht schwankt, weil die Erdrotation nicht gleichförmig ist. Deshalb wurde die SI-Sekunde eingeführt. Seitdem ist die genaue Definition:
Eine Sekunde ist das 9.192.631.770-fache der Periodendauer der dem Übergang zwischen den beiden Hyperfeinstrukturniveaus des Grundzustandes von Atomen des Nuklids 133Cs entsprechenden Strahlung.
Damit ist die Sekunde nicht mehr an die Erdrotation geknüpft. Dadurch kommt es zu leichten Abweichungen gegenüber der astronomischen Zeit (meistens mehrere Millisekunden pro Tag). Nun gibt es verschiedene Zeitsysteme. Das sind zum Beispiel:
- GMT: Ist hoffnungslos veraltet (bereits seit 1928). GMT wird immer noch oft angegeben, jedoch ist damit meistens UTC gemeint.
- Dann gibt es noch UT1 (oft auch einfach nur UT genannt). UT1 ist der Nachfolger der GMT. Es ist nicht an die SI-Sekunde gebunden. Wenn ein Tag etwas kürzer ist, als der vorherige, dann ist auch jede Sekunden dieses Tages etwas kürzer. Somit ist die Sekundenzahl immer konstant, die Länge jeder Sekunde aber unterschiedlich.
- TAI ist rein physikalisch. Jede Sekunde entspricht der SI-Sekunde und jeder Tag hat 86.400 Sekunden. Somit weicht TAI von der astronomischen Zeit ab. 1958 wurde TAI auf die aktuelle Zeit von UT1 gesetzt. Seitdem ist die Differenz zwischen TAI und UT1 schon bei 35 Sekunden (Stand: Juli 2012).
- UTC ist die am häufigsten gebrauchte Zeit. Eine Sekunde bei UTC entsprechen immer einer SI-Sekunde. Es ist also vergleichbar mit TAI. Jedoch ist garantiert, dass UTC maximal 0,9 Sekunden von UT1 abweicht. Das wird durch Schaltsekunden realisiert.
Schaltsekunden sind sehr ähnlich wie ein Schaltjahr, nur das nicht ein ganzer Tag eingefügt wird, sondern nur eine Sekunde. Außerdem lassen sich Schaltsekunden nicht auf längere Sicht bestimmen, da die Unregelmäßigkeiten der Erdrotation nur schwer vorhersehbar sind. Deshalb wird von einer Organisation (IERS) regelmäßig bestimmt, wann die nächste Schaltsekunde "auftreten" soll.
Okay, das hat jetzt erstmal nicht viel mit Informatik zutun. Aber es ist sicherlich nettes Background-Wissen.
Unix Timestamp und die Schaltsekunde
Wie verhält sich der Unix Timestamp nun bei einer Schaltsekunde? Angenommen, ich hätte im Jahr 2000 einen Unixrechner aufgesetzt. Dann hätte er bereits drei Schaltsekunden verpasst. Zumindest, sofern kein NTP daemon o.Ä. vorhanden gewesen wäre, über den der Rechner die Schaltsekunden erfahren könnte.
Wenn es eine positive Schaltsekunde gibt, also eine zusätzliche Sekunden eingefügt wird (bisher waren alle Schaltsekunden positiv), dann springt der Timestamp tatsächlich um eine Sekunde zurück. Da er dies am Ende eines Tages (also um 23:59:59) macht, sieht es so aus, als wenn er für eine Sekunde stillstehen würde.
Ich nehme einmal die Schaltsekunde vom 30. Juni 2012 (nach 23:59:59) als Beispiel. Zwischen der UTC Zeit 2012-06-30T23:59:59 und 2012-07-01T00:00:00 ist nicht eine Sekunde vergangen, sondern zwei. Der Timestamp zählt diese Sekunde nicht und bleibt bei 1341187199 für ebenfalls zwei Sekunden "hängen". Der Timestamp wächst also nicht linear.
Das dadurch entstehende Problem...
...ist zugegebenerweise in den meisten Fällen nicht oder nur von sehr geringer Relevanz. Die meisten Programmierer haben sicher schon einmal sowas gemacht:
$time0 = mktime(0, 0, 0, 1, 1, 2012);
$time1 = mktime(0, 0, 0, 9, 9, 2012);
echo "Sekunden zwischen dem 01.01 und 09.09.2012: ";
echo ($time1 - $time0);
Das Ergebnis ist, je nach Parameter, nicht richtig. Es kann um einige Sekunden falsch sein, da die Schaltsekunde nicht beachtet wurde.
Dieses Problem sollte man sich immer im Hinterkopf bewahren, wenn man irgendetwas mit Zeiten macht. Egal ob man diese konvertiert, damit rechnet, oder sonst was tut. Dem Nutzer wäre die Differenz jedoch vermutlich nicht aufgefallen. Auffallen würde es aber zum Beispiel, wenn ein System sagt, dass ein Zertifikat um 13:37:42 Uhr abläuft, ein anderes aber errechnet, dass es um 13:37:43 Uhr abläuft. Streng genommen ist also auch der Unix Timestamp nicht für die einfache Berechnung von Zeitdifferenzen zu gebrauchen.
Die häufig vereinfachte Definition "Sekunden seit 01.01.1970, 00:00" ist also falsch. Wenn es danach ging, würde der Timestamp schon heute um 25 Sekunden falsch gehen.
Und jetzt erklärt mir bitte auch einer, was der "Übergang zwischen den beiden Hyperfeinstrukturniveaus des Grundzustandes von Atomen des Nuklids 133Cs" ist. :-)