Epoch-Zeit erklärt
Epoch-Zeit ist das Fundament dafür, wie Computer Zeit verfolgen. Das Verständnis dieses Konzepts hilft Ihnen, mit Timestamps zu arbeiten, zeitbezogene Probleme zu debuggen und häufige Fallstricke in der Zeitverarbeitung zu vermeiden.
Warum der 1. Januar 1970?
Die Wahl des 1. Januar 1970 als Unix-Epoch war etwas willkürlich, aber nicht zufällig. Als Unix in den späten 1960er Jahren bei Bell Labs entwickelt wurde, brauchte das Team einen Referenzpunkt für Zeitberechnungen. Sie wählten ein Datum, das aktuell genug war, um praktisch zu sein, aber weit genug in der Vergangenheit, um etwas historische Abdeckung zu haben. Das ursprüngliche Unix-System verwendete einen 32-Bit vorzeichenbehafteten Integer für Timestamps. Dieser konnte Zeiten vom 13. Dezember 1901 bis zum 19. Januar 2038 darstellen – ein 136-Jahre-Fenster. Die Platzierung der Epoch in 1970 setzte sie ungefähr in die Mitte dieses Bereichs und gab sowohl historische als auch zukünftige Abdeckung. Warum nicht der 1. Januar 1900, wie einige andere Systeme? Teilweise weil der 32-Bit-Bereich sich nicht so weit zurück erstrecken würde, wenn Sie nützliche zukünftige Daten wollten. Teilweise weil 1970 "jetzt" war, als die Entscheidungen getroffen wurden. Die Ingenieure haben wahrscheinlich nicht vorhergesehen, dass wir ihre Entscheidungen 50+ Jahre später noch verwenden würden. Andere Systeme haben andere Epochs. Microsoft Windows verwendet den 1. Januar 1601 (bezogen auf Kalenderreformberechnungen). Apples klassisches Mac OS verwendete den 1. Januar 1904. NTP (Network Time Protocol) verwendet den 1. Januar 1900. GPS verwendet den 6. Januar 1980. Jedes hatte seine eigenen praktischen Gründe, aber Unix's Epoch wurde der De-facto-Standard für die meiste Datenverarbeitung. Interessanterweise fällt die Unix-Epoch auf einen Donnerstag. Das bedeutet, Sie können den Wochentag aus einem Timestamp berechnen: (timestamp / 86400 + 4) mod 7, wobei 0 = Sonntag und 4 = Donnerstag.
Das Y2K38-Problem
Das Y2038-Problem (auch Unix-Millennium-Bug oder Y2K38 genannt) ist ein echtes Anliegen für Systeme, die 32-Bit-Timestamps verwenden. Am 19. Januar 2038 um 03:14:07 UTC werden 32-Bit vorzeichenbehaftete Timestamps von ihrem Maximalwert (2.147.483.647) auf ihren Minimalwert (-2.147.483.648) überlaufen, von 2038 auf 1901 springend. Die Mathematik ist einfach: 2^31 - 1 = 2.147.483.647 Sekunden nach der Epoch ist der 19. Januar 2038, 03:14:07 UTC. Eine Sekunde später wickelt der vorzeichenbehaftete Integer zu negativ um, was als 13. Dezember 1901 interpretiert wird. Dies ähnelt Y2K, ist aber schwieriger zu lösen. Y2K betraf Datums-Strings, wo Fixes oft einfache Textänderungen waren. Y2038 betrifft binäre Datenformate, kompilierten Code und Hardware, die Zeiten als 32-Bit-Integer speichert. Sie können nicht einfach eine Datenbank aktualisieren – Sie müssen Datentypen ändern, was möglicherweise Kompatibilität bricht. Welche Systeme sind gefährdet? Eingebettete Systeme (Autos, IoT-Geräte, industrielle Steuerungen) verwenden oft 32-Bit-Prozessoren und haben lange Lebensdauern. Datenbanksysteme mit 32-Bit-Timestamp-Spalten. Dateiformate, die 32-Bit-Timestamps speichern. Legacy-Anwendungen, die nicht aktualisiert wurden. Die Lösung sind 64-Bit-Timestamps. Ein 64-Bit vorzeichenbehafteter Integer unterstützt Daten von etwa 292 Milliarden Jahren in der Vergangenheit bis 292 Milliarden Jahren in der Zukunft – weit über die Lebensdauer der Sonne hinaus. Die meisten modernen Systeme haben bereits auf 64-Bit-Zeit umgestellt. Sie könnten Y2038-Probleme vor 2038 begegnen, wenn Systeme zukünftige Daten berechnen (Hypotheken, Garantien, Abonnements), die über den Überlaufpunkt hinausgehen. Eine 30-jährige Hypothek, die 2010 ausgestellt wurde, würde 2040 enden, nach dem 32-Bit-Limit.
Negative Timestamps
Timestamps vor der Unix-Epoch (1. Januar 1970) werden als negative Zahlen dargestellt. Dies ermöglicht Unix-Systemen, historische Daten zu handhaben, ohne ein anderes Zeitformat zu benötigen. Der Timestamp -1 ist der 31. Dezember 1969, 23:59:59 UTC – eine Sekunde vor der Epoch. Timestamp -86400 (negative einen Tag in Sekunden) ist der 31. Dezember 1969, 00:00:00 UTC. Das Muster setzt sich in die Geschichte fort. Auf 32-Bit-Systemen mit vorzeichenbehafteten Integern gehen negative Timestamps zurück bis zum 13. Dezember 1901. Auf 64-Bit-Systemen erstreckt sich der Bereich auf Milliarden von Jahren – weiter als jedes praktische historische Datum. Historische Daten haben Komplikationen jenseits negativer Timestamps. Vor 1972 existierte UTC nicht – die Zeit basierte auf GMT und verschiedenen nationalen Standards. Vor 1582 (Einführung des Gregorianischen Kalenders) werden Datumsberechnungen komplex, weil verschiedene Regionen zu unterschiedlichen Zeiten unterschiedliche Kalender verwendeten. Sommerzeit erzeugt zusätzliche Komplexität für historische Timestamps. Als sich Sommerzeit-Regeln änderten (und sie haben sich in verschiedenen Regionen viele Male geändert), könnte dieselbe lokale Zeit zu unterschiedlichen Timestamps vor und nach der Regeländerung abbilden. Schaltsekunden, eingeführt 1972, bedeuten, dass einige Minuten 61 Sekunden haben. Die meisten Timestamp-Systeme ignorieren Schaltsekunden (Unix-Zeit tut so, als existierten sie nicht), was eine kleine angesammelte Diskrepanz zwischen Unix-Zeit und tatsächlicher UTC erzeugt.
Tool ausprobieren
Zeitstempel-Konverter