Was ist ein Unix-Timestamp? Erklärung mit Beispielen
Ein Unix-Timestamp ist die Anzahl der Sekunden, die seit dem 1. Januar 1970, 00:00:00 UTC vergangen sind. Dieser Referenzpunkt heißt Unix-Epoch, und der Timestamp selbst ist einfach eine einzige, immer wachsende Zahl statt eines formatierten Datums. Ein Wert wie 1700000000 in einer Datenbankzeile oder einer API-Antwort ist genau dieser Sekundenzähler, kein Zufallswert.
Was ein Unix-Timestamp eigentlich ist
Statt “14. November 2023, 22:13:20 UTC” zu speichern, speichert ein System einfach 1700000000, die Anzahl der Sekunden bis zu diesem Moment. Das klingt zunächst weniger lesbar, ist für Computer aber deutlich praktischer: Ein Timestamp ist eine einzelne Ganzzahl, die sich ohne String-Parsing vergleichen, sortieren und subtrahieren lässt. Möchtest du wissen, ob ein Ereignis vor einem anderen lag, reicht ein simpler Zahlenvergleich. Möchtest du die Dauer zwischen zwei Ereignissen berechnen, ziehst du die eine Zahl von der anderen ab und bekommst direkt die Sekundenanzahl dazwischen.
Genauso wichtig: Ein Unix-Timestamp ist zeitzonenunabhängig. Er beschreibt einen absoluten Moment im Universum, keine Uhrzeit auf einem bestimmten Zifferblatt. Eine Datenbankspalte created_at, ein exp-Claim in einem JWT-Token oder ein Zeilenanfang in einer Logdatei speichern deshalb meist genau diese Zahl statt eines formatierten Strings wie “14.11.2023 22:13:20” mit einer daran hängenden Zeitzonenangabe, die früher oder später falsch interpretiert wird.
Ein weiterer Vorteil zeigt sich, sobald mehrere Systeme miteinander reden müssen. Ein Server in Frankfurt, ein Client in São Paulo und ein Log-Aggregator in Singapur können jeweils ihre eigene lokale Uhrzeit anzeigen, speichern aber intern denselben Timestamp. Erst beim Rendern für Menschen wird daraus wieder ein lesbares Datum in der jeweils gewünschten Zeitzone, die Rohdaten bleiben dabei unverändert und eindeutig vergleichbar, egal wo auf der Welt sie erzeugt wurden.
Praxisbeispiel: reale Timestamp-Werte lesen
Die folgende Tabelle zeigt fünf konkrete Timestamps und das dazugehörige UTC-Datum:
| Unix-Timestamp (Sekunden) | Datum und Uhrzeit in UTC |
|---|---|
| 0 | 1. Januar 1970, 00:00:00 UTC (der Epoch selbst) |
| 1000000000 | 9. September 2001, 01:46:40 UTC |
| 1700000000 | 14. November 2023, 22:13:20 UTC |
| 2000000000 | 18. Mai 2033, 03:33:20 UTC |
| 2147483647 | 19. Januar 2038, 03:14:07 UTC |
Nimm den dritten Wert als Beispiel: 1700000000 Sekunden seit dem 1. Januar 1970 sind knapp 53,9 Jahre, was dich mitten ins Jahr 2023 führt, konkret auf den 14. November um 22:13:20 UTC. Du musst diese Rechnung nie von Hand durchführen, aber es hilft, sich klarzumachen, dass hinter der Zahl tatsächlich nur ein simpler Zähler steckt, der seit 1970 ununterbrochen hochzählt. Der letzte Wert in der Tabelle, 2147483647, ist kein Zufall, dazu gleich mehr im Abschnitt über Sonderfälle.
Auch der zweite Wert lohnt einen kurzen Blick: 1000000000, also eine glatte Milliarde Sekunden, fiel auf den 9. September 2001. Solche runden Zahlen tauchen in Testdaten, Beispiel-Snippets und Tutorials auffällig oft auf, gerade weil sie sich leicht merken lassen, auch wenn das dahinterliegende Datum auf den ersten Blick beliebig wirkt. Und 2000000000, zwei Milliarden Sekunden nach dem Epoch, liegt noch in der Zukunft, am 18. Mai 2033, ein guter Test dafür, ob eine Anwendung mit Zukunftsdaten sauber umgeht.
Sekunden oder Millisekunden? So unterscheidest du sie
Der häufigste Stolperstein bei Unix-Timestamps ist die Einheit. Ein Timestamp in Sekunden hat heute 10 Ziffern, etwa 1700000000. Derselbe Moment in Millisekunden hat 13 Ziffern: 1700000000000, ebenfalls der 14. November 2023, nur tausendmal feiner aufgelöst.
Das ist kein akademischer Unterschied. JavaScripts Date.now() und viele Web-APIs liefern Millisekunden zurück, während Unix-Systemaufrufe, cron und die meisten klassischen Unix- und Linux-Werkzeuge mit Sekunden arbeiten. Fügst du versehentlich einen Millisekunden-Wert in ein Feld ein, das Sekunden erwartet, rechnet das Tool die Zahl 1000-fach zu hoch und landet dadurch weit in der Zukunft, oft mehrere Jahrhunderte voraus. Ein Timestamp, der plötzlich ins Jahr 55000 zeigt, ist fast immer genau dieser Einheitenfehler und keine echte Anomalie in den Daten.
Ein typischer Fall: Du liest ein Ablaufdatum aus einem exp-Claim eines JWT-Tokens aus, das in Sekunden angegeben ist, übergibst den Wert aber an eine JavaScript-Funktion, die einen Millisekunden-Timestamp erwartet. Statt in wenigen Stunden zu verfallen, wirkt der Token dann so, als wäre er erst in ferner Zukunft ungültig, weil die Sekundenzahl fälschlich als Millisekunden interpretiert wurde und der berechnete Zeitpunkt tausendmal weiter in der Zukunft liegt als beabsichtigt. Genau umgekehrt passiert es, wenn ein Millisekunden-Wert versehentlich als Sekunden gelesen wird: Dann landet die Berechnung nicht in der Zukunft, sondern nur wenige Minuten nach 1970, weit in der Vergangenheit.
Einen Timestamp in ein Datum umrechnen
Hast du einen rohen Timestamp aus einer Logdatei, einer Datenbankzeile oder einer API-Antwort vor dir und willst wissen, welches konkrete Datum sich dahinter verbirgt, gibst du ihn einfach unten ein.
Ein Datum in einen Timestamp umrechnen
Der umgekehrte Fall kommt genauso oft vor: Du planst etwas für ein bestimmtes Datum und eine bestimmte Uhrzeit, zum Beispiel einen cron-Job, der um Mitternacht laufen soll, oder ein Ablaufdatum für einen JWT-Token, und brauchst dafür den passenden Unix-Timestamp für deine API oder Konfigurationsdatei.
Häufige Fehler und Sonderfälle
Sekunden mit Millisekunden verwechseln. Wie oben beschrieben ist das der klassische Fehler: Eine 13-stellige Zahl in ein Feld einzufügen, das 10-stellige Sekundenwerte erwartet, verschiebt das Ergebnis um den Faktor 1000. Ein Blick auf die Ziffernanzahl verrät sofort, welche Einheit du vor dir hast.
Das Jahr-2038-Problem. Systeme, die einen Timestamp als vorzeichenbehaftete 32-Bit-Ganzzahl speichern, können maximal 2147483647 darstellen, also den 19. Januar 2038, 03:14:07 UTC. Eine Sekunde später läuft der Wert über und springt auf eine negative Zahl, was Datumslogik in älterer Software zuverlässig durcheinanderbringt. Moderne 64-Bit-Systeme kennen diese Grenze praktisch nicht, weil ihr Zahlenraum um ein Vielfaches größer ist.
Zeitzonenverwirrung, obwohl der Timestamp selbst keine Zeitzone kennt. Ein Unix-Timestamp beschreibt einen absoluten Moment, keine lokale Uhrzeit. Die Verwirrung entsteht erst bei der Anzeige: Zeigst du denselben Timestamp in UTC und in einer lokalen Zeitzone an, bekommst du zwei unterschiedliche Uhrzeiten für exakt denselben Augenblick. Zwei Personen in unterschiedlichen Zeitzonen, die auf denselben Timestamp schauen, sehen unterschiedliche Uhrzeiten auf ihrer Uhr, aber es handelt sich um denselben Moment.
Negative Timestamps für Daten vor 1970. Ein negativer Wert wie -86400 steht für den 31. Dezember 1969, also einen Tag vor dem Epoch. Nicht jedes Tool und nicht jedes System unterstützt negative Timestamps, deshalb solltest du das vorher prüfen, wenn du mit historischen Daten vor 1970 arbeitest, etwa Geburtsdaten oder archivierten Dokumenten.
Rundungsfehler beim manuellen Umrechnen. Wer eine Dauer in Tagen, Stunden und Minuten von Hand in Sekunden umrechnet und dabei einen Zwischenschritt falsch überträgt, etwa eine unterschiedliche Anzahl Tage pro Monat oder ein Schaltjahr übersieht, bekommt einen Timestamp, der um Minuten, Stunden oder sogar einen ganzen Tag daneben liegt. Für exakte Werte lohnt sich fast immer ein Rechner statt Kopfrechnen, gerade bei Datumsspannen über mehrere Monate.
Häufig gestellte Fragen
Was ist ein Unix-Timestamp? Ein Unix-Timestamp ist die Anzahl der Sekunden, die seit dem 1. Januar 1970, 00:00:00 UTC vergangen sind, dem sogenannten Unix-Epoch. Er wird universell in der Programmierung verwendet, um einen genauen Zeitpunkt eindeutig darzustellen, ohne dass eine Zeitzone mit angegeben werden muss.
Wie erkenne ich, ob mein Timestamp in Sekunden oder Millisekunden vorliegt?
Zähl die Ziffern. Aktuelle Sekunden-Timestamps haben 10 Stellen, etwa 1700000000. Millisekunden-Timestamps haben 13 Stellen, etwa 1700000000000. JavaScript und viele Web-APIs liefern Millisekunden, während cron und klassische Unix-Werkzeuge Sekunden verwenden.
Was ist das Jahr-2038-Problem? Systeme, die einen Timestamp als vorzeichenbehaftete 32-Bit-Ganzzahl speichern, laufen am 19. Januar 2038 um 03:14:07 UTC über und springen dann auf eine negative Zahl, was Datumsberechnungen zerstört. Moderne 64-Bit-Systeme sind davon nicht betroffen, weil ihr Wertebereich weit über diesen Zeitpunkt hinausreicht.
Kann ich ein Datum vor 1970 umrechnen? Ja, dafür verwendest du einen negativen Unix-Timestamp. -86400 entspricht zum Beispiel dem 31. Dezember 1969, also einen Tag vor dem Epoch. Beachte allerdings, dass nicht jedes Tool oder System negative Timestamps korrekt verarbeitet.
Warum speichern Datenbanken Daten als Unix-Timestamp statt als Datumsstring?
Weil ein Timestamp eine einzelne Ganzzahl ist, die sich ohne String-Parsing sortieren, vergleichen und subtrahieren lässt, und weil er keine Zeitzonen-Mehrdeutigkeit mit sich bringt. Eine Spalte created_at als Timestamp lässt sich direkt für Bereichsabfragen und Sortierungen nutzen, während ein formatierter Datumsstring erst wieder geparst werden müsste.
Warum zeigt mein Timestamp ein Datum weit in der Vergangenheit oder Zukunft, obwohl er richtig aussieht? Das ist fast immer die Sekunden-Millisekunden-Verwechslung aus dem Abschnitt oben. Prüf zuerst die Ziffernanzahl: 10 Stellen bedeuten Sekunden, 13 Stellen bedeuten Millisekunden. Wird ein Millisekunden-Wert als Sekunden gelesen, landet das Ergebnis nur wenige Minuten nach 1970, wird ein Sekundenwert als Millisekunden gelesen, landet es weit in der Zukunft.