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
The Unix epoch (1970-01-01 UTC) was inherited from Multics, the OS that influenced early Unix design. POSIX later standardized the time_t type with explicit semantics that differ from how the original Unix specs described it — and most other platforms count from a different epoch entirely.
- Multics (1969) counted seconds from 1970-01-01 GMT; Unix adopted the same epoch in 1971
- POSIX time_t is defined as a count of seconds since 1970 UTC, explicitly excluding leap seconds (every day is 86,400 ticks)
- POSIX vs Unix terminology: in practice the two are used interchangeably; POSIX is the standardized name
- Other software epochs differ widely:
- Windows FILETIME — 1601-01-01 UTC (Gregorian-cycle start), 100-nanosecond intervals
- .NET DateTime.Ticks — 0001-01-01, 100-nanosecond intervals
- Apple / Core Data — 2001-01-01 UTC (Cocoa reference date), seconds
- NTP — 1900-01-01 UTC, seconds; GPS — 1980-01-06, seconds (no leap seconds)
- Julian Day — noon UT, 4713 BC (proleptic Julian), days
- When importing time data, confirm the epoch before trusting the value as Unix time
Related articles
FAQ
- Is epoch time always in seconds?
- The classic Unix timestamp is seconds since 1970-01-01 00:00:00 UTC, but many systems use milliseconds, microseconds, or nanoseconds with the same epoch.
- Can Unix timestamps represent dates before 1970?
- Yes. Negative timestamps represent dates before the Unix epoch, though older libraries and databases may not support them.
- Does a Unix timestamp include a timezone?
- No. A Unix timestamp represents one instant in UTC. Timezone information is used only when converting that instant into a readable local date.
- What is the maximum Unix timestamp?
- It depends on the storage type, not the epoch. A 32-bit signed integer maxes out at 2,147,483,647 (January 19, 2038), while a 64-bit integer or a JavaScript number reaches hundreds of millions of years. See the Year 2038 problem for the details.