Epoch-Zeit erklärt: Was ist Unix-Timestamp null?
Der Unix-Timestamp 0 ist der 1. Januar 1970 um 00:00:00 UTC. Lerne, warum dieses Datum zur Unix-Epoch wurde, was negative Timestamps darstellen, wie sich Epoch-Sekunden/-Millisekunden/-Mikrosekunden unterscheiden und welche Grenzen für moderne Systeme gelten.
Was der Unix-Timestamp 0 darstellt
Jeder Unix-Timestamp zählt die seit einem einzigen Bezugspunkt verstrichene Zeit: dem 1. Januar 1970 um 00:00:00 UTC. In der ursprünglichen Unix-Definition ist die Einheit die Sekunde, also ist Timestamp 0 exakt Mitternacht UTC am 1. Januar 1970 und Timestamp 86400 exakt 24 Stunden später. Moderne Systeme nutzen auch Millisekunden, Mikrosekunden und Nanosekunden, aber der Bezugspunkt ist derselbe. Jeder positive Wert steht für einen Moment nach der Epoch, jeder negative für einen davor.
Warum der 1. Januar 1970?
Das Datum wählten Unix-Entwickler bei Bell Labs Anfang der 1970er als praktischen Bezugspunkt, kurz vor der Entstehung von Unix selbst. Es musste früh genug sein, damit normale System-Timestamps positiv sind, jung genug, um in die kleinen Ganzzahlbereiche früher Computer zu passen, und einfach genug, um es im Kopf zu prüfen. Als Unix einflussreich wurde, übernahmen Sprachen, Betriebssysteme, Datenbanken, Logformate und Netzwerkprotokolle denselben Startpunkt.
- Unix wurde ab 1969 bei Bell Labs entwickelt — die Epoch wurde kurz davor gesetzt
- Der 1. Januar wurde als saubere Kalendergrenze gewählt
- 1970 statt 1969, weil die Implementierung einen bei null beginnenden Zähler nutzte
- Jedes moderne OS, jede Sprache und jedes Protokoll erbte diese Epoch — es gibt keinen konkurrierenden Standard
Negative Timestamps: Daten vor 1970
Negative Unix-Timestamps stehen für Momente vor dem 1. Januar 1970 00:00:00 UTC. Die meisten modernen 64-Bit-Systeme unterstützen sie korrekt, was für historische Daten, Geburtsdaten, Archivsätze und die Interoperabilität mit Systemen nützlich ist, deren Epochs früher als die von Unix beginnen. Ältere Bibliotheken und Datenbanken lehnen negative Werte eventuell ab, daher verdienen historische Datensätze eine explizite Kompatibilitätsprüfung.
- -1 = December 31, 1969 23:59:59 UTC (one second before the epoch)
- -86400 = December 31, 1969 00:00:00 UTC (one day before the epoch)
- -2208988800 = January 1, 1900 00:00:00 UTC
- JavaScript: new Date(-86400 * 1000).toISOString() → '1969-12-31T00:00:00.000Z'
Praktische Grenzen des Formats
Die Unix-Epoch selbst ist nicht die Grenze; der Speichertyp ist es. Ein in einer vorzeichenbehafteten 32-Bit-Ganzzahl gespeicherter Timestamp versagt viel früher als einer in einer 64-Bit-Ganzzahl, einer JavaScript-Zahl oder einem nativen Datenbank-Timestamp-Typ. Frage bei der Bewertung der Timestamp-Sicherheit sowohl nach der Einheit als auch nach dem numerischen Speichertyp.
- 32-bit signed integer max: 2,147,483,647 = January 19, 2038 03:14:07 UTC (the Year 2038 problem)
- JavaScript Date max: 8,640,000,000,000,000 ms = September 13, 275760 CE
- 64-bit signed integer max: ~9.2 × 10^18 seconds = year ~292 billion
- PostgreSQL TIMESTAMPTZ max: January 1, 294276 CE
Die Epochs anderer Systeme
Unix ist nicht die einzige in der Informatik genutzte Epoch. Andere Systeme definierten aus historischen oder technischen Gründen eigene Bezugspunkte.
- GPS-Epoch: 6. Januar 1980 00:00:00 UTC — von GPS-Satelliten und -Empfängern genutzt
- Windows FILETIME: 1. Januar 1601 00:00:00 UTC — 100-Nanosekunden-Intervalle
- Apple Cocoa / NSDate: 1. Januar 2001 00:00:00 UTC
- Excel / Lotus 1-2-3: 1. Januar 1900 — mit einem absichtlichen Schaltjahr-Bug zur Lotus-Kompatibilität
- FAT-Dateisystem: 1. Januar 1980 00:00:00 lokale Zeit
Epoch-Sekunden, -Millisekunden, -Mikrosekunden und -Nanosekunden
Das Wort Timestamp verrät nicht immer die Einheit. Unix-Sekunden sind in Betriebssystemen und Backend-Sprachen üblich. Unix-Millisekunden sind in JavaScript und Browser-APIs üblich. Mikro- und Nanosekunden tauchen in Datenbanken, Tracing-Systemen und hochauflösenden Logs auf. Die Einheit steuert sowohl die Präzision als auch die sichtbare Stellenzahl.
- Seconds: 1700000000 — common in Python, PHP, Go, Ruby, C, and Unix command-line tools
- Milliseconds: 1700000000000 — common in JavaScript Date and many web analytics systems
- Microseconds: 1700000000000000 — common in some databases and event pipelines
- Nanoseconds: 1700000000000000000 — common in high-resolution tracing and systems languages
- Always document the unit when storing epoch values in APIs, CSV files, and database columns
Epoch-Zeit vs. UTC vs. lokale Zeit
Epoch-Zeit ist eine Zählung. UTC ist der globale Zeitstandard, der den Bezugsmoment definiert. Lokale Zeit ist eine Anzeigewahl auf Basis einer Zeitzone wie America/New_York oder Asia/Tokyo. Ein Unix-Timestamp ändert sich nicht, wenn ein Nutzer reist; nur das formatierte Kalenderdatum und die Uhrzeit ändern sich.
- Derselbe Timestamp kann in verschiedenen Zeitzonen als verschiedene lokale Daten erscheinen
- UTC-Ausgabe ist am besten für Logs, APIs und serverübergreifendes Debugging
- Lokale Ausgabe ist am besten für Kalender, Oberflächen und Berichte
- Zeitzonen-Offsets werden beim Formatieren angewandt, nicht im Unix-Timestamp gespeichert
FAQ zur Epoch-Zeit
- Ist Epoch-Zeit immer in Sekunden?
- Der klassische Unix-Timestamp ist in Sekunden seit 1970-01-01 00:00:00 UTC, aber viele Systeme nutzen Millisekunden, Mikrosekunden oder Nanosekunden mit derselben Epoch.
- Können Unix-Timestamps Daten vor 1970 darstellen?
- Ja. Negative Timestamps stehen für Daten vor der Unix-Epoch, auch wenn ältere Bibliotheken und Datenbanken sie nicht unterstützen.
- Enthält ein Unix-Timestamp eine Zeitzone?
- Nein. Ein Unix-Timestamp steht für einen Moment in UTC. Zeitzonen-Infos werden nur beim Umwandeln dieses Moments in ein lesbares lokales Datum genutzt.
- Was ist der maximale Unix-Timestamp?
- Das hängt vom Speichertyp ab, nicht von der Epoch. Eine vorzeichenbehaftete 32-Bit-Ganzzahl reicht maximal bis 2,147,483,647 (19. Januar 2038), während eine 64-Bit-Ganzzahl oder eine JavaScript-Zahl Hunderte Millionen Jahre erreicht. Siehe das Jahr-2038-Problem für Details.