Unix-Zeit und Epoch-Timestamps verständlich erklärt
Die Unix-Zeit (auch bekannt als Posix-Zeit oder Epoch-Timestamp) ist ein System zur Darstellung von Zeitpunkten in der Informatik. Sie definiert die Zeit als die Anzahl der Sekunden, die seit dem Nullpunkt, der sogenannten Unix-Epoche, vergangen sind.
Die Unix-Epoche ist definiert als der 1. Januar 1970 um 00:00:00 Uhr Koordinierte Weltzeit (UTC).
Da es sich bei der Unix-Zeit um eine einfache, kontinuierlich ansteigende Ganzzahl (Integer) handelt, ist sie für Computersysteme extrem einfach zu speichern, zu sortieren und zu verarbeiten. Sie ist unabhängig von Zeitzonen, Sommerzeit-Regelungen oder länderspezifischen Datumsformaten.
Genau diese Eigenschaft macht die Unix-Zeit zum Quasi-Standard für maschinenlesbare Zeitangaben: Sie taucht in JSON-APIs, in Datenbank-Zeitstempeln, in Cron-Logs und in JWT-Ablaufzeiten (exp-Claim) auf. Überall dort wird ein eindeutiger, zeitzonenfreier Zahlenwert benötigt.
Sekunden vs. Millisekunden: Die häufigste Fehlerquelle
In der Praxis ist die grösste Stolperfalle nicht die Epoche selbst, sondern die Einheit. Verschiedene Systeme zählen in unterschiedlichen Granularitäten:
| Einheit | Stellen (2026) | Beispiel | Typische Quelle |
|---|---|---|---|
| Sekunden | 10 | 1781956200 | Unix-Tools, PHP time(), JWT exp |
| Millisekunden | 13 | 1781956200000 | JavaScript Date.now(), Java |
| Mikrosekunden | 16 | 1781956200000000 | High-Precision-Logs |
Faustregel zur Erkennung: Ein heutiger Sekunden-Zeitstempel beginnt mit 17... und hat 10 Stellen. Hat ein Wert 13 Stellen, liegt er fast sicher in Millisekunden und muss vor der Umrechnung in ein Datum durch 1000 geteilt werden.
Wie die Unix-Zeit funktioniert
In der Unix-Zeit entspricht jede Sekunde einem Inkrement von 1.
Datum & Uhrzeit (UTC) Unix-Timestamp
─────────────────────────────────────────────
01.01.1970 00:00:00 0
01.01.1970 00:00:01 1
31.12.1999 23:59:59 946'684'799
09.09.2001 01:46:40 1'000'000'000 (Die erste Milliarde)
20.06.2026 11:50:00 1'781'956'200 (Beispiel)
Da der Zeitstempel global immer in UTC gemessen wird, ist der Wert zu jedem Zeitpunkt auf der ganzen Welt identisch. Die Umrechnung in die lokale Uhrzeit eines Nutzers (z. B. Schweizer Mitteleuropäische Sommerzeit - MESZ) erfolgt ausschliesslich bei der visuellen Darstellung im Webbrowser oder Betriebssystem durch Hinzuaddieren oder Subtrahieren des Zeitzonen-Offsets.
Das Jahr-2038-Problem (Y2K38)
Ein grosses Thema im Software-Engineering und Technical SEO (bezüglich Legacy-Systemen) ist das sogenannte Jahr-2038-Problem (auch bekannt als Y2K38-Bug).
Die Ursache
In älteren 32-Bit-Betriebssystemen und Programmiersprachen wird die Unix-Zeit standardmässig als vorzeichenbehaftete 32-Bit-Ganzzahl (signed 32-bit integer) gespeichert. Der maximale Wert, den eine solche Variable speichern kann, liegt bei 2’147’483’647.
Der Überlauf
Dieser Wert wird exakt am 19. Januar 2038 um 03:14:07 Uhr UTC erreicht. In der darauffolgenden Sekunde läuft der Zähler über und springt in den negativen Bereich auf -2'147'483'648. Für das Computersystem entspricht dieser Zeitpunkt dann plötzlich dem 13. Dezember 1901 um 20:45:52 Uhr UTC. Dies führt unweigerlich zu schweren Systemabstürzen, fehlerhaften Datenbankabfragen und blockierter Software.
Die Lösung
Moderne Computersysteme, Betriebssysteme und Datenbanken wurden bereits vor Jahren auf 64-Bit-Ganzzahlen (signed 64-bit integer) umgestellt. Ein 64-Bit-Integer bietet genügend Platz, um die Unix-Zeit für die nächsten 292 Milliarden Jahre (bis weit nach dem Ende unseres Sonnensystems) fehlerfrei zu speichern. Kritisch sind heute nur noch eingebettete Systeme (IoT-Geräte) oder sehr alte, ungepflegte Software-Applikationen.
Best Practices für Entwickler
- Verwenden Sie 64-Bit-Variablen: Deklarieren Sie Zeitstempel-Datenbankspalten immer als 64-Bit-Integer (BIGINT in SQL) statt als 32-Bit-Integer (INT).
- Millisekunden-Präzision beachten: JavaScript (z. B.
Date.now()) und viele moderne APIs nutzen standardmässig Millisekunden anstelle von Sekunden seit 1970. Eine 13-stellige JS-Zeitstempel-Zahl (z. B.1781956200000) muss vor der Konvertierung in Standard-Unix-Sekunden durch 1000 geteilt werden. - Vorsicht bei Schaltsekunden: Wenn Ihre Software extrem präzise Messdaten (im Millisekunden- oder Mikrosekunden-Bereich) verarbeitet, sollten Sie sich bewusst sein, dass Unix-Zeitstempel Schaltsekunden durch “Zeit-Stauchung” (Time Smearing) ausgleichen.
Praxisbeispiel: Ein falsch interpretierter Zeitstempel
Ein klassischer Bug entsteht, wenn eine JavaScript-Anwendung Zeitstempel an ein Backend sendet, das Sekunden erwartet:
- Vorher (fehlerhaft): Das Frontend ruft
Date.now()auf und sendet1781956200000(Millisekunden). Das PHP-Backend interpretiert den Wert direkt mitdate()als Sekunden – und zeigt als Datum das Jahr 58366 an. In der Datenbank stehen völlig unbrauchbare Sortierwerte. - Nachher (korrekt): Das Frontend teilt den Wert vor dem Senden durch 1000 (
Math.floor(Date.now() / 1000)) und übergibt1781956200. Backend, Datenbank und Frontend rechnen nun einheitlich in Sekunden, und das Datum wird korrekt als 20.06.2026 dargestellt.
Die Lehre: Legen Sie für jedes System klar fest, in welcher Einheit Zeitstempel gespeichert und übertragen werden – und dokumentieren Sie diese Konvention. Die meisten Datums-Bugs entstehen an der Schnittstelle zwischen Sekunden und Millisekunden.
Unix-Zeit in verschiedenen Sprachen
Fast jede Programmiersprache bietet eine eingebaute Funktion, um den aktuellen Epoch-Wert zu ermitteln:
| Sprache | Aktueller Zeitstempel | Einheit |
|---|---|---|
| JavaScript | Math.floor(Date.now()/1000) | Sekunden |
| Python | int(time.time()) | Sekunden |
| PHP | time() | Sekunden |
| Java | System.currentTimeMillis() | Millisekunden |
| Bash/Linux | date +%s | Sekunden |
| SQL (Postgres) | EXTRACT(EPOCH FROM now()) | Sekunden |
Wer Werte zwischen diesen Systemen austauscht, sollte die Einheit – wie oben gezeigt – immer explizit angleichen, idealerweise auf Sekunden als gemeinsamen Nenner.
[!TIP] Müssen Sie einen aktuellen Unix-Zeitstempel in ein für Menschen lesbares Datum umrechnen oder ein konkretes Datum in einen Epoch-Wert konvertieren? Nutzen Sie den Epoch Converter auf balou.tools für eine schnelle und direkte Umrechnung im Browser.
Häufig gestellte Fragen (FAQ)
Warum beginnt die Unix-Zeit genau am 1. Januar 1970?
Das Datum 01.01.1970 00:00:00 UTC wird als "Unix-Epoche" bezeichnet. Es wurde willkürlich von den Unix-Entwicklern Ende der 1960er Jahre als Systemstartzeitpunkt (Nullpunkt) gewählt, da dies die Implementierung der Zeitberechnung vereinfachte.
Wie viele Sekunden hat ein Tag in der Unix-Zeit?
Ein Standard-Tag hat in der Unix-Zeit exakt 86'400 Sekunden. Schaltsekunden werden von der Unix-Zeit ignoriert, indem die Sekunde 23:59:59 UTC entweder wiederholt oder gestreckt wird, um den Zeitstempel synchron zur Erdrotation zu halten.
Woran erkenne ich, ob ein Zeitstempel in Sekunden oder Millisekunden vorliegt?
An der Stellenzahl: Ein Sekunden-Zeitstempel hat aktuell 10 Stellen (z. B. 1781956200), ein Millisekunden-Zeitstempel 13 Stellen (z. B. 1781956200000). Interpretiert eine Software Millisekunden fälschlich als Sekunden, landet das Datum rund 50000 Jahre in der Zukunft – ein häufiger Bug bei der Verarbeitung von JavaScript-Zeitstempeln.
Sollte ich Zeitstempel in der Datenbank als UTC oder lokale Zeit speichern?
Immer in UTC. Da die Unix-Zeit per Definition auf UTC basiert, entfällt jede Zeitzonen-Mehrdeutigkeit. Die Umrechnung in die lokale Zeit der Nutzer erfolgt erst bei der Anzeige. So vermeiden Sie Fehler durch Sommerzeit-Umstellungen und Server in unterschiedlichen Zeitzonen.