ISO-8601-Datum-Zeit-Format erklärt
ISO 8601 ist der internationale Standard zur Darstellung von Datum und Uhrzeit als Zeichenketten. Seine kanonische Form — 2024-03-15T14:30:00Z — ist eindeutig, sortierbar und wird in jeder modernen Sprache und Datenbank unterstützt. Dieser Leitfaden behandelt das Format Komponente für Komponente, die RFC-3339-Teilmenge, die die meisten APIs tatsächlich nutzen, die neuere RFC-9557-Zeitzonenerweiterung sowie die Varianten für Dauern, Intervalle und Wochendaten.
Was ist ISO 8601?
ISO 8601 ist die Darstellung von Datum und Uhrzeit der Internationalen Organisation für Normung. Die aktuelle Version (ISO 8601-1:2019 / -2:2019) definiert ein kompaktes, geordnetes, sprachneutrales Textformat. Ihr ganzer Zweck ist es, Mehrdeutigkeit zu beseitigen: Ein Datum wie 03/04/2024 ist in den USA der 4. März und in weiten Teilen Europas der 3. April, aber 2024-03-04 bedeutet überall dasselbe. Der Standard ist auch die Grundlage für RFC 3339, das Profil, das die meisten Internetprotokolle tatsächlich verwenden.
- Reihenfolge Jahr-Monat-Tag, immer: 2024-03-15 (nicht 03/15/2024 oder 15/03/2024)
- Zeitanteil durch ein wörtliches T oder ein Leerzeichen getrennt: 2024-03-15T14:30:00
- Zeitzone explizit: Z für UTC oder ±HH:MM für einen Offset
- Als Text sortierbar — lexikografische Reihenfolge entspricht der chronologischen
Das kanonische Datum-Zeit-Format
Die häufigste Form sieht aus wie 2024-03-15T14:30:00.123Z. Jede Komponente hat eine feste Breite und führende Nullen, und genau das macht das Format sortierbar und eindeutig.
| Komponente | Beispiel | Bedeutung |
|---|---|---|
| YYYY | 2024 | Vierstellige Jahreszahl |
| MM | 03 | Zweistelliger Monat (01–12) |
| DD | 15 | Zweistelliger Tag (01–31) |
| T | T | Trennzeichen Datum/Zeit (RFC 3339 erlaubt auch ein Leerzeichen) |
| hh:mm:ss | 14:30:00 | 24-Stunden-Zeit, mit führenden Nullen |
| .fff | .123 | Optionale Sekundenbruchteile (in ISO 8601 beliebige Präzision) |
| Z oder ±hh:mm | Z | Zeitzonenkennung (Z = UTC = +00:00) |
Zeitzonenkennungen
ISO-8601-Zeitzonen werden als Offsets von UTC kodiert, nie als Zonenkürzel wie EST oder CET (die mehrdeutig sind). Die Zeichenkette trägt genug Information, um den exakten UTC-Zeitpunkt zu rekonstruieren, einschließlich der Halbstunden- und 45-Minuten-Offsets, die einige Regionen verwenden.
| Kennung | Offset von UTC | Beispielzone |
|---|---|---|
| Z | +00:00 | UTC ("Zulu"-Zeit) |
| +09:00 | 9 Stunden voraus | Japanische Standardzeit |
| -05:00 | 5 Stunden zurück | US-amerikanische Eastern Standard Time |
| +05:30 | 5,5 Stunden voraus | Indische Standardzeit |
| +05:45 | 5,75 Stunden voraus | Nepalesische Standardzeit |
| (keine) | unbestimmt | Lokale Zeit — mehrdeutig; in APIs vermeiden |
ISO 8601 vs. RFC 3339
RFC 3339 ist ein Profil von ISO 8601 — restriktiver und leichter zu parsen. Die meisten Internetprotokolle (JSON-APIs, HTTP, IETF-Spezifikationen) zielen speziell auf RFC 3339 ab, wenn eine API also "ISO 8601" sagt, meint sie fast immer die RFC-3339-Teilmenge. Die Unterschiede sind klein, entscheiden aber, ob eine gegebene Zeichenkette parst.
| Merkmal | ISO 8601 | RFC 3339 |
|---|---|---|
| Trennzeichen Datum/Zeit | T, oder im Basisformat weggelassen | T oder ein einzelnes Leerzeichen (erforderlich) |
| Zeitzonen-Offset | Optional | Erforderlich |
| Sekundenbruchteile | Beliebige Präzision | Erlaubt, vom Parser begrenzt |
| Basisformat (ohne Bindestriche) | 20240315T143000Z erlaubt | Nicht erlaubt |
| Wochen-/Ordinaldaten | Erlaubt | Nicht erlaubt |
| Typische Nutzung | Archive, Tabellen, Austausch | JSON-APIs, HTTP, IETF-Spezifikationen |
RFC 9557: Zeitzonen und die Temporal-Erweiterung
Ein bloßer Offset wie +01:00 nennt dir den Zeitpunkt, aber nicht die Zeitzone — und Offsets ändern sich mit der Sommerzeit, dieselbe Zone ist also im Winter +01:00 und im Sommer +02:00. RFC 9557 (2024) schließt diese Lücke mit dem Internet Extended Date/Time Format (IXDTF): Es hängt den IANA-Zonennamen in Klammern an, wie in 2024-03-15T14:30:00+01:00[Europe/Paris]. Das ist das Zeichenkettenformat, das die JavaScript-Temporal-API liest und schreibt, du wirst es also mit zunehmender Temporal-Verbreitung häufiger sehen. Es bleibt abwärtskompatibel — entferne das Klammer-Suffix und du hast einen gewöhnlichen RFC-3339-Timestamp.
- Nur Offset: 2024-03-15T14:30:00+01:00 — der Zeitpunkt, aber nicht die Zone
- IXDTF (RFC 9557): 2024-03-15T14:30:00+01:00[Europe/Paris] — Zeitpunkt plus Zone
- Abwärtskompatibel: Das Klammer-Tag kann von RFC-3339-Parsern ignoriert werden
Varianten: Dauern, Intervalle, Wochendaten
ISO 8601 deckt mehr als nur Zeitpunkte ab. Mehrere Varianten kommen in Planungs-, Archivierungs- und Berichtssystemen regelmäßig vor:
- Dauern: P3Y6M4DT12H30M5S = 3 Jahre, 6 Monate, 4 Tage, 12 Stunden, 30 Minuten, 5 Sekunden
- Intervalle: 2024-01-01/2024-02-01, oder 2024-01-01/P1M (Start + Dauer)
- Ordinaldaten: 2024-075 = der 75. Tag des Jahres 2024 (15. März)
- Wochendaten: 2024-W11-5 = Freitag der ISO-Woche 11 des Jahres 2024
- Wiederkehrende Intervalle: R3/2024-01-01/P1D = drei eintägige Intervalle ab 1. Januar
ISO 8601 im Code
Jede gängige Sprache kann die RFC-3339-Teilmenge von Haus aus erzeugen und parsen. Die sicherste Gewohnheit ist, UTC mit einem Z auszugeben und zurück zu einem Zeitpunkt zu parsen und jede Zeitzonenumrechnung der Anzeigeschicht zu überlassen.
- JavaScript ausgeben: new Date().toISOString() // '2024-03-15T14:30:00.123Z'
- JavaScript parsen: new Date('2024-03-15T14:30:00Z') // RFC-3339-Teilmenge
- Python ausgeben: datetime.now(timezone.utc).isoformat()
- Python parsen: datetime.fromisoformat('2024-03-15T14:30:00+00:00') // vollständiges ISO ab 3.11
- Die meisten Datenbanken (Postgres, SQLite) akzeptieren und liefern ISO 8601 timestamptz direkt
Häufige ISO-8601-Fehler
Selbst mit einem strikten Standard macht parsender und erzeugender Code dieselbe Handvoll Fehler:
- Die Zeitzone weglassen: 2024-03-15T14:30:00 ohne Z oder Offset ist mehrdeutig
- "+0000" statt "+00:00" verwenden — manche Parser akzeptieren es, RFC 3339 nicht
- Ein Nicht-Buchstaben-T verwenden (Unicode-Doppelgänger kopieren sich schlecht)
- 12-Stunden-AM/PM in ISO 8601 mischen — es ist immer 24-Stunden
- Sekundenbruchteile ohne Runden abschneiden — wähle eine Präzision und bleib dabei
- ISO 8601 als gebietsschema-abhängig behandeln — ist es nicht; das Format ist sprachunabhängig fest
Verwandte Referenzen
FAQ
- Ist "2024-03-15 14:30:00Z" gültiges ISO 8601?
- Ja — das Leerzeichen zwischen Datum und Zeit ist in ISO 8601 (und in RFC 3339) erlaubt. Die T-Form ist für eindeutiges maschinelles Parsen vorzuziehen.
- Was bedeutet das Z am Ende?
- Z bedeutet UTC (Offset +00:00). Es ist die Kurzform für "Zulu-Zeit", das NATO-/Luftfahrt-Buchstabieralphabet für den Buchstaben Z.
- Wie parse ich ISO 8601 in JavaScript?
- new Date("2024-03-15T14:30:00Z") funktioniert für die Standard-RFC-3339-Teilmenge. Für umfassendere ISO-8601-Unterstützung nutze eine Bibliothek wie date-fns oder die Temporal-API.
- Ist ISO 8601 dasselbe wie RFC 3339?
- Nein — RFC 3339 ist eine strikte Teilmenge. Jeder RFC-3339-Timestamp ist gültiges ISO 8601, aber nicht jeder ISO-8601-Timestamp ist gültiges RFC 3339.
- Was ist RFC 9557?
- RFC 9557 (2024) erweitert RFC 3339 um das Internet Extended Date/Time Format (IXDTF). Es hängt den IANA-Zonennamen in Klammern an — zum Beispiel 2024-03-15T14:30:00+01:00[Europe/Paris] — und liegt dem Zeichenkettenformat der JavaScript-Temporal-API zugrunde.
- Ist das T-Trennzeichen erforderlich?
- In striktem ISO 8601 kann das T im Basisformat weggelassen werden; RFC 3339 erfordert ein T oder ein einzelnes Leerzeichen. Für maschinelles Parsen immer das T einfügen.
- Was ist der Unterschied zwischen ISO 8601 und ISO 8601-2?
- ISO 8601-1 deckt die grundlegende Datums- und Zeitdarstellung ab. ISO 8601-2 (die Erweiterung von 2019) fügt neue Konstrukte wie unsichere Daten, qualifizierende Werte und komplexe Intervalle hinzu.