Unix-Timestamps erklaert - Epoch, ISO-8601 und Zeitzonen

Veroeffentlicht am 19. April 2026

---

Jedes Serverlog, jede Datenbankzeile und jede API-Antwort im Internet kodiert "wann etwas passiert ist" in einem von vier Formaten: dem Unix-Epoch (Sekunden oder Millisekunden), ISO 8601 oder RFC 2822. Wenn Sie schon einmal einen Timestamp in Slack eingefuegt haben, nur um zu streiten, in welcher Zeitzone er war, ist dieser Leitfaden fuer Sie. Er behandelt, was jedes Format tatsaechlich kodiert, wie man zwischen ihnen konvertiert, und die drei Fallstricke, die auch erfahrene Entwickler erwischen.

Unix-Epoch: Sekunden seit 1970-01-01 UTC

Der Unix-Timestamp - auch "Epoch-Zeit" genannt - ist die Anzahl der Sekunden, die seit 00:00:00 UTC am 1. Januar 1970 vergangen sind. Dieser Referenzpunkt ist willkuerlich, aber universell; jedes von Unix abgeleitete System (Linux, macOS, Android, iOS) und fast jede Programmiersprache verfolgt die Zeit intern als Zaehlung von diesem Moment aus.

Ein aktueller Wert: 1776495426 uebersetzt sich zu 2026-04-18 12:17:06 UTC. Es gibt keine Zeitzone, die in der Zahl selbst kodiert ist - sie ist immer UTC - was sowohl eine Staerke (keine Ambiguitaet, wenn zwei Systeme Timestamps vergleichen) als auch eine Falle ist (was auch immer die Zahl in einen menschenlesbaren String konvertiert, muss eine Zeitzone waehlen, und es waehlt normalerweise die lokale).

Sekunden vs Millisekunden: die erste Quelle der Verwirrung

JavaScript, Java und die meisten modernen Sprach-Standardbibliotheken verwenden standardmaessig Millisekunden seit dem Epoch, nicht Sekunden. Derselbe Moment - 2026-04-18 12:17:06 UTC - ist 1776495426 in Sekunden (10 Ziffern), aber 1776495426000 in Millisekunden (13 Ziffern). Eine schnelle Faustregel zur Plausibilitaetspruefung eines Timestamps, den Sie erhalten haben:

• 10 Ziffern → Sekunden (Unix-Kommandozeile, PHP, Python time.time(), Go).
• 13 Ziffern → Millisekunden (JavaScript Date.now(), Java System.currentTimeMillis(), die meisten JSON-APIs).
• 16 oder 19 Ziffern → Mikrosekunden oder Nanosekunden (spezialisierte Telemetrie und wissenschaftliche Zeitmessung).

Ein 10-stelliger Sekundenwert, der als Millisekunden interpretiert wird, rendert als Datum im Jahr 1970 (50+ Jahre zu frueh). Ein 13-stelliger Millisekundenwert, der als Sekunden interpretiert wird, rendert als Datum ~56.000 n. Chr. Beide Fehler sind sofort sichtbar, sobald der Timestamp konvertiert wird - verwenden Sie Convert Milliseconds to Date zur Plausibilitaetspruefung oder Get Current Time in Milliseconds zum Vergleich mit dem Jetzt.

ISO 8601: das lesbare Austauschformat

ISO 8601 ist ein menschenlesbares Datums-Zeit-Format, dem auch Maschinen zustimmen. Die kanonische Form sieht so aus: 2026-04-18T12:17:06.520Z. Teile:

• Datum: 2026-04-18 (YYYY-MM-DD, immer in dieser Reihenfolge).
• Trennzeichen: T (literaler Buchstabe T zwischen Datum und Zeit).
• Zeit: 12:17:06.520 (HH:MM:SS.sss, 24 Stunden).
• Zeitzone: Z fuer UTC oder ein Offset wie +07:00 / -05:30 fuer andere Zonen.

ISO 8601 ist eindeutig (keine regionale Datumsverwirrung wie 04-18 vs 18-04), sortierbar als einfacher String (die lexikalische Reihenfolge entspricht der chronologischen Reihenfolge, wenn die Zeitzone gleich ist), und wird von jedem modernen Parser unterstuetzt. Wenn Sie die API kontrollieren, die Sie bauen, bevorzugen Sie ISO-8601-Strings gegenueber rohen Unix-Epoch-Zahlen - sie tragen die Zeitzone explizit, was eine ganze Klasse von Bugs eliminiert.

RFC 2822: das alte E-Mail- und HTTP-Format

RFC 2822 (und das fast identische HTTP-Datum aus RFC 7231) sieht so aus: Sat, 18 Apr 2026 12:17:06 +0000. Es ist das Format, das Sie in E-Mail-Date:-Headern, HTTP-Last-Modified-Headern und einigen aelteren Web-APIs sehen werden. Es ist lesbar, aber nicht als einfacher String sortierbar (das Wochentags-Praefix bricht die lexikalische Reihenfolge), so dass Systeme zunehmend ISO 8601 neben oder anstelle von RFC 2822 zurueckgeben. Wenn Sie RFC 2822 manuell generieren muessen, verwenden Sie eine Bibliothek, anstatt den String selbst zu bauen - der Wochentagsname und die Monatsabkuerzung sind locale-sensitiv und leicht zu verwechseln.

UTC vs Ortszeit: die Wurzel der meisten Timestamp-Bugs

Unix-Epoch-Timestamps sind immer UTC; ISO-8601-Strings koennen UTC (Z) oder jeder Offset sein; RFC 2822 traegt fast immer einen Offset. Aber wenn ein Programm einen Timestamp anzeigt, konvertiert es normalerweise in die lokale Zeitzone der anzeigenden Maschine.

Das ist fuer einen einzelnen Benutzer in Ordnung, verursacht aber in drei Szenarien Chaos:

• Einen Timestamp im Chat teilen. "Der Deploy passierte um 14:00" ist mehrdeutig - wessen 14:00? Fuegen Sie den ISO-8601-Wert (2026-04-18T14:00:00+07:00) ein oder geben Sie die Zeitzone explizit an.
• Logs von mehreren Servern. Setzen Sie jeden Server auf UTC. Immer. Log-Aggregatoren und Incident-Response-Tools nehmen UTC an; das Mischen von Zeitzonen in Logs ist der schnellste Weg, eine Ursache-Wirkungs-Kette falsch zuzuordnen.
• Benutzerorientierte Zeitplaene. Speichern Sie die Ereigniszeit in UTC (oder in der Quellzeitzone des Ereignisses mit explizitem Offset) und konvertieren Sie zur Anzeigezeit. Speichern Sie nicht "19 Uhr" ohne Zeitzone; "19 Uhr" in der Sitzung eines Benutzers kann 16 Uhr fuer einen anderen sein.

Drei haeufige Fallstricke (und wie man sie erkennt)

1. Integer-vs-String-Timestamps in JSON. JavaScripts JSON.parse erzeugt treu eine Zahl fuer 1776495426520 - aber wenn die API denselben Timestamp als String "1776495426520" zurueckgegeben hat, wird jeder nachfolgende Code, der Arithmetik darauf ausfuehrt, ihn stillschweigend coercen. Pruefen Sie immer den Typ, bevor Sie ihn an new Date() uebergeben.

2. Monat 0-11 in JavaScript Date. new Date(2026, 3, 18) ist der 18. April 2026, nicht der 18. Maerz 2026. Der Monat ist 0-indiziert, aber Tag und Jahr sind 1-indiziert. Bevorzugen Sie den ISO-8601-Konstruktor (new Date("2026-04-18")), der der natuerlichen Nummerierung folgt.

3. DST-Uebergaenge. In der Nacht "Vorstellen", existiert 2:30 Uhr Ortszeit nicht; in der Nacht "Zurueckstellen", passiert 1:30 Uhr zweimal. Wenn Ihr System lokale Zeitstrings speichert, erzeugen diese Momente unmoegliche oder duplizierte Timestamps. UTC-Speicherung beseitigt das Problem; Date-Bibliotheken wie Luxon oder date-fns-tz behandeln die Konvertierung explizit.

Verwandte Werkzeuge

• Convert Milliseconds to Date - Timestamp einfuegen, formatierte UTC- und Ortsdatum erhalten.
• Get Current Time in Milliseconds - Live-Epoch-Ablesung, jede Sekunde aktualisiert.
• MD5 Converter - String fuer Checksums oder Deduplikationsschluessel hashen.
• JSON Parser - API-Antworten mit Timestamp-Feldern inspizieren.

← Zurueck zu Utility Tools