Skip to content

Der Anbeginn der Zeit und dessen Ende

Wenn jemand mit Computern zu tun hat, ist er sicherlich schonmal auf den Begriff StartOfEpoch gestoßen, die mit dem 1. Januar 1970 festgesetzt ist.

Und wer’s nicht bereits weiss, der wird sich vielleicht auch überlegt haben, warum der Anbeginn der Zeit (ok, ich übertreibe hier ein wenig), gerade auf dieses Datum fällt. Die Erklärung ist relativ einfach, eigentlich trivial: Irgendwann muss die in Computern verwendete Zeitrechnung ja beginnen. 1972 wurde dieser Beginn für den 1.1.1970 festgesetzt. So einfach ist das. Wer’s komplizierter haben will, der kann sich Wikipedia:Unixtime zu Gemüte führen.

Die StartOfEpoch wird auch als UnixEpoch bezeichnet. Das liegt daran, dass dieser Referenzpunkt für die computermäßige Zeitmessung zuerst in Unix-Systemen großflächig eingesetzt wurde.

Ein Datum wird computerintern als Sekunden seit StartOfEpoch bez. UnixEpoch dargestellt und auch Unix-Zeit genannt. Es werden negative Zahlen verwendet, um Daten vor dem Start der Epoche zu repräsentieren. Die Hälfte des zur Verfügung stehenden Zahlenbereichs geht hierfür drauf.

In Computern hat die Genauigkeit einer Zahlendarstellung allerdings irgendwann seine Grenzen. D.h. die Genauigkeit oder – wie hier – die Länge einer Zahl ist beschränkt. Im Eintrag Beliebig genaue Gleitkommazahlen habe ich schonmal eine Möglichkeit beschrieben, wie man Ungenauigkeit zumindest im Fall von Gleitkommazahlen einschränken (bzw. beliebig hinauszögern) kann. Aber auch hier gilt: Irgendwann ist Schluß. Auch eine beliebig genaue Gleitkommazahl muss eine festgesetzte, definierte maximale Länge besitzen. Im Falle der Unix-Zeit wurde diese Länge auf 32 Bit festgesetzt. Damals war Speicher teuer und man konnte sich nicht leisten eine Länge zu verwenden, die der Menschheit mit Sicherheit reichen würde. Welche Länge das ist, wird weiter unten klar werden.

In 32 Bit können 2^(32) Sekunden dargestellt werden. Wie lange wird das reichen? Ein wenig Rechnen ist angesagt:

import math
secRepresentable = math.pow(2, 32)
secADay = 60 * 60 * 24
daysRepresentable = secRepresentable / secADay
yearsRepresentable = daysRepresentable / 365
half = yearsRepresentable / 2

ergibt folgende Werte:

secRepresentable     = 4294967296.0
secADay              = 86400
daysRepresentable    = 49710.2696296
yearsRepresentable   = 136.192519533

Und weil die Hälfte des Zahlenraums für negative Zeitangaben reserviert ist, folgt schließlich:

>>>1970 + half
2038.096259766616

Die 32 Bit reichen also bis 2038. Finito.

Wenn man hingegen statt der 32 Bit ganze 64 verwendet, ergibt sich ein anderes Bild:

secRepresentable = 1.84467440737e+019
secADay = 86400
daysRepresentable = 2.13503982335e+014
yearsRepresentable = 584942417355.0
>>>1970 + half
292471210648.0

Mit 64 Bit hat man also bis ins Jahr 292,5 Millarden kein Überlauf-Problem.

Übrigens hat das ‚Jahr 2038‘-Problem nichts mit dem ‚Jahr 2000‘-Problem zu tun. Zumindest nicht technisch. Eher aus ökonomischen Gründen, denn das Y2K-Problem, wie es auch genannt wird, hat seine Ursache ebenfalls im Mangel an Speicherplatz: Man hat bei Jahreszahlen nur die letzten beiden Stellen gespeichert. Und dann gilt 1900 == 2000, aber auch 2000 == 12500, etc.. Warum Geiz aus anderen Gründen nicht geil ist, werde ich aber in einem anderen Beitrag kurz erläutern.

Post a Comment

Your email is never published nor shared. Required fields are marked *