Unix-Timestamp-Format vs. ISO 8601: Was solltest Du verwenden?

Wer schon einmal zwei Systeme integriert hat, die Datumsangaben unterschiedlich speichern, kennt das Problem. Eine API liefert 1714521600, eine andere 2024-05-01T00:00:00Z – und plötzlich schreibst du um Mitternacht Konvertierungslogik. Wer von Anfang an das richtige Format wählt, spart stundenlange Fehlersuche und verhindert stille Bugs in der Produktion. Beide Formate sind weit verbreitet, beide haben echte Stärken, und keines ist grundsätzlich überlegen. Entscheidend ist zu verstehen, wann welches Format passt – und warum die falsche Wahl reale Kosten verursacht.

Was ist das Unix-Timestamp-Format?

Ein Unix-Timestamp (auch Unix Time oder Epoch Time genannt) ist ein einzelner Integer, der die Anzahl der Sekunden seit der Unix Epoch angibt: dem 1. Januar 1970, 00:00:00 UTC. Das Unix-Zeitformat ist per Definition zeitzonenunabhängig, da es sich immer auf UTC bezieht. Mehrdeutigkeiten durch Sommerzeit oder regionale Offsets gibt es nicht.

Der Unix-Timestamp 1714521600 steht zum Beispiel für genau einen bestimmten Moment in der Zeit – egal, wo auf der Welt du ihn auswertest. Moderne Systeme erweitern das oft auf Millisekunden (1714521600000) oder Mikrosekunden für höhere Präzision. Mehr zu diesen Varianten erfährst du in unserem Leitfaden zu Sekunden vs. Millisekunden vs. Mikrosekunden bei Unix-Timestamps.

Technisch gesehen ist ein Unix-Timestamp schlicht eine Zahl. Diese Einfachheit ist gleichzeitig seine größte Stärke und die Ursache seines offensichtlichsten Nachteils: der fehlenden Lesbarkeit.

Mehr Hintergrundwissen zum Ursprung dieses Konzepts findest du in unserem Artikel über Epoch Time und ihre Grundlagen.

Was ist das ISO-8601-Datumsformat?

ISO 8601 ist ein internationaler Standard der Internationalen Organisation für Normung, der festlegt, wie Datums- und Zeitangaben als Strings dargestellt werden. Ein typischer ISO-8601-Datetime-Wert sieht so aus: 2024-05-01T00:00:00Z.

Die einzelnen Bestandteile:

• 2024-05-01 – das Datum im Format YYYY-MM-DD
• T – Trennzeichen zwischen Datum und Uhrzeit
• 00:00:00 – die Uhrzeit im Format HH:MM:SS
• Z – steht für UTC (alternativ können Offsets wie +05:30 verwendet werden)

ISO 8601 bildet die Grundlage des RFC-3339-Standards, der in Internetprotokollen weit verbreitet ist. Das Format ist menschenlesbar, als String sortierbar und sprachunabhängig eindeutig. Anders als „05/01/2024" – das in den USA den 1. Mai, in Deutschland aber den 5. Januar bedeutet – ist ISO 8601 weltweit konsistent.

Die wichtigsten Unterschiede im Überblick

Wann solltest du Unix-Timestamps verwenden?

Das Unix-Zeitformat glänzt in klar definierten Situationen. Verwende es, wenn:

1. Du Datumsberechnungen durchführst

Zeitspannen lassen sich mit Unix-Timestamps trivial berechnen. Um herauszufinden, wie viele Sekunden vergangen sind, subtrahierst du einfach einen Integer vom anderen. Bei ISO-8601-Strings musst du zunächst beide Werte in Datetime-Objekte parsen und dann die Differenz berechnen. Bei hochfrequenten Operationen – etwa beim Loggen von Millionen von Ereignissen – summiert sich dieser Parsing-Overhead erheblich.

2. Du Datumsangaben in Datenbanken speicherst

Integer-Spalten lassen sich schneller indizieren und vergleichen als String-Spalten. Für Abfragen wie „alle Ereignisse der letzten 7 Tage" ist der Vergleich zweier Integer effizienter als das Parsen und Vergleichen von Strings. Unser ausführlicher Leitfaden zu Unix-Timestamps in Datenbanken behandelt Indexierungsstrategien und Abfragemuster im Detail.

3. Du zwischen internen Services kommunizierst

Wenn zwei Backend-Services, die du selbst kontrollierst, Timestamps austauschen müssen, reduziert das Unix-Format die Parsing-Komplexität. Beide Seiten einigen sich auf den Integer-Vertrag, und es besteht kein Risiko einer Fehlinterpretation von Zeitzonen-Strings.

4. Du Ablauf- und TTL-Logik implementierst

JWT-Tokens, Cache-Einträge und Session-Ablaufzeiten werden nahezu universell als Unix-Timestamps ausgedrückt. Der exp-Claim in einem JSON Web Token (JWT) ist genau aus diesem Grund ein Unix-Timestamp: Der Vergleich exp > Date.now() / 1000 ist ein einziger schneller Integer-Vergleich.

5. Du Zeitzonenfehler vermeiden willst

Da Unix-Timestamps immer UTC sind, eliminieren sie eine ganze Klasse von Sommerzeit-Bugs. Wenn deine Anwendung Nutzer in mehreren Zeitzonen bedient, ist es ein bewährtes Architekturmuster, Unix-Timestamps zu speichern und erst bei der Ausgabe in die lokale Zeit umzuwandeln.

Wenn du 32-Bit-Integer zur Speicherung von Unix-Timestamps verwendest, solltest du das Jahr-2038-Problem kennen – verwende in modernen Systemen immer 64-Bit-Integer.

Wann solltest du ISO 8601 verwenden?

Das ISO-8601-Datumsformat ist überall dort die bessere Wahl, wo Menschen oder externe Systeme Datumsangaben lesen, schreiben oder validieren müssen, ohne Code auszuführen.

1. API-Antworten für Drittanbieter

Wenn du eine öffentliche API baust, ist "created_at": "2024-05-01T12:30:00Z" deutlich entwicklerfreundlicher als "created_at": 1714562200. Externe Entwickler können den Wert sofort verstehen, ohne ihn konvertieren zu müssen. Viele API-Styleguides – darunter die von Stripe und GitHub – verwenden ISO 8601 standardmäßig aus genau diesem Grund.

2. Log-Dateien und Audit-Trails

Logs werden von Menschen bei Incidents gelesen. Eine Log-Zeile wie [2024-05-01T14:22:05Z] ERROR: Zahlung fehlgeschlagen ist sofort verwertbar. Ein Log mit [1714569725] ERROR: Zahlung fehlgeschlagen zwingt den Lesenden, den Timestamp erst zu konvertieren, bevor er überhaupt mit der Fehlersuche beginnen kann.

3. Internationalisierung und Lokalisierung

ISO 8601 enthält explizite Zeitzonen-Offset-Informationen. Wenn dein System die ursprüngliche Ortszeit des Nutzers erhalten muss – zum Beispiel ein Kalendereintrag, der um 9:00 Uhr in Tokio erstellt wurde – erfasst ISO 8601 mit dem korrekten Offset (2024-05-01T09:00:00+09:00) diese Information vollständig. Ein Unix-Timestamp allein kann nicht ausdrücken, in welcher Zeitzone der Nutzer war, als er das Ereignis erstellt hat.

4. Konfigurationsdateien und Datenaustauschformate

JSON-, YAML- und CSV-Dateien, die Menschen bearbeiten, sollten ISO 8601 verwenden. Wenn ein Entwickler ein Ablaufdatum manuell in einer Konfigurationsdatei setzen muss, ist 2025-01-01T00:00:00Z deutlich fehlerunanfälliger als das manuelle Berechnen und Eintragen eines Unix-Timestamps.

Codebeispiele in JavaScript und Python

JavaScript: Konvertierung zwischen den Formaten

// Aktuellen Unix-Timestamp ermitteln (Sekunden)
const unixNow = Math.floor(Date.now() / 1000);
console.log(unixNow); // z. B. 1714521600

// Unix-Timestamp in ISO-8601-String umwandeln
const isoString = new Date(unixNow * 1000).toISOString();
console.log(isoString); // "2024-05-01T00:00:00.000Z"

// ISO-8601-String zurück in Unix-Timestamp umwandeln
const parsed = new Date("2024-05-01T00:00:00Z");
const backToUnix = Math.floor(parsed.getTime() / 1000);
console.log(backToUnix); // 1714521600

// Zeitspanne zwischen zwei Unix-Timestamps berechnen (kein Parsing nötig)
const start = 1714521600;
const end = 1714608000;
const durationSeconds = end - start;
console.log(`Dauer: ${durationSeconds / 3600} Stunden`); // 24 Stunden

Python: Arbeiten mit beiden Formaten

import time
from datetime import datetime, timezone

# Aktuellen Unix-Timestamp ermitteln
unix_now = int(time.time())
print(unix_now)  # z. B. 1714521600

# Unix-Timestamp in ISO-8601-String umwandeln
dt = datetime.fromtimestamp(unix_now, tz=timezone.utc)
iso_string = dt.isoformat()
print(iso_string)  # "2024-05-01T00:00:00+00:00"

# ISO-8601-String zurück in Unix-Timestamp umwandeln
parsed_dt = datetime.fromisoformat("2024-05-01T00:00:00+00:00")
back_to_unix = int(parsed_dt.timestamp())
print(back_to_unix)  # 1714521600

# Zeitspanne berechnen – mit Unix-Timestamps trivial
start = 1714521600
end = 1714608000
duration_hours = (end - start) / 3600
print(f"Dauer: {duration_hours} Stunden")  # 24.0 Stunden

Praxisbeispiel: Buchungssystem

Stell dir vor, du baust eine Hotel-Buchungs-API. Ein Nutzer in New York bucht ein Zimmer für den Check-in am 15. Juni 2024 um 15:00 Uhr Ortszeit. So verhalten sich die beiden Formate in der Praxis unterschiedlich.

Speicherung als Unix-Timestamp: Du konvertierst die Ortszeit des Nutzers in UTC und speicherst 1718470800. Das ist kompakt und schnell abzufragen. Wenn das Hotelpersonal in New York jedoch den rohen Datenbankdatensatz ansieht, sieht es eine Zahl – und braucht ein Werkzeug, um sie zu dekodieren. Schlimmer noch: Vergisst du, vor dem Speichern von Ortszeit in UTC umzurechnen, hast du einen stillen 4-Stunden-Bug eingebaut (New York hat im Sommer UTC-4).

Speicherung als ISO 8601: Du speicherst 2024-06-15T15:00:00-04:00. Der Offset bleibt erhalten. Das Personal kann den Datensatz direkt lesen. Die ursprüngliche Zeitzoneninformation geht nicht verloren. Allerdings sind String-Vergleiche in SQL etwas langsamer, und die Berechnung von „wie viele Stunden bis zum Check-in" erfordert zunächst das Parsen des Strings.

Die Lösung, die die meisten Teams in der Produktion einsetzen: Den Unix-Timestamp in der Datenbank speichern – für Performance und Korrektheit – und in der API-Antwort den ISO-8601-String zurückgeben – für Benutzerfreundlichkeit. Dieses Muster verwenden die großen Plattformen. Du bekommst das Beste aus beiden Welten.

Eine vollständige Übersicht der Konvertierungsmuster findest du in unserem vollständigen Leitfaden zur Unix-Timestamp-Konvertierung.

Klare Empfehlung nach Anwendungsfall

Basierend auf realen Anforderungen, hier eine direkte Empfehlung für jeden Anwendungsfall:

• Datenbankspeicherung: Unix-Timestamp (Integer). Schnellere Indizierung, kein Zeitzonenparser, geringerer Speicherbedarf.
• Interne Microservice-Kommunikation: Unix-Timestamp. Beide Seiten kontrollieren den Vertrag, und kein Mensch liest den rohen Payload.
• Öffentliche REST-API-Antworten: ISO 8601. Externe Entwickler benötigen lesbare, selbsterklärende Werte.
• Log-Dateien und Audit-Trails: ISO 8601. Menschen lesen Logs unter Druck bei Incidents.
• JWT- und Session-Ablauf: Unix-Timestamp. Die Spezifikation schreibt es vor, und Vergleiche sind eine einzige Operation.
• Konfigurationsdateien und geplante Aufgaben: ISO 8601. Menschen schreiben und bearbeiten diese Dateien direkt.
• Kalender- und Planungsfunktionen: ISO 8601 mit explizitem Zeitzonen-Offset. Bewahrt die ursprüngliche Zeitzoneninformation des Nutzers.
• Datumsarithmetik in der Anwendungslogik: Zuerst in Unix-Timestamp umwandeln, berechnen, dann bei Bedarf zurückkonvertieren.

Einen umfassenderen Satz an Best Practices für die Arbeit mit Timestamps im Backend-Code findest du in unserem Unix-Timestamp-Tutorial für Entwickler, das Muster für Speicherung, Formatierung und Zeitzonenbehandlung ausführlich behandelt.

Fazit

Die Frage Unix-Timestamp-Format versus ISO-8601-Datumsformat ist keine Frage, welches Format besser ist. Es geht darum, das richtige Werkzeug für den richtigen Zweck einzusetzen. Unix-Timestamps gehören in deine Datenbankspalten, deine internen Service-Verträge und deine Ablauflogik. ISO 8601 gehört in deine API-Antworten, deine Logs und in jede Datei, die ein Mensch öffnen könnte. Die meisten robusten Produktivsysteme nutzen beide Formate: intern als Unix-Timestamp speichern, nach außen als ISO 8601 ausgeben. Wer dieses eine Muster verinnerlicht, vermeidet die häufigsten Datums-Bugs, bevor sie jemals die Produktion erreichen.

Schluss mit dem Rätselraten beim Datumsformat

Probiere unseren kostenlosen Unix-Timestamp-Konverter auf unixtimestamp.app und wandle Unix-Zeit und ISO 8601 sofort ineinander um – ganz ohne Code. Timestamp einfügen, lesbares Datum in Sekunden erhalten.

Jetzt kostenlos ausprobieren →