RFC 3339 · · Proposed Standard
Das Timestamp-Format, das du zehnmal pro Woche googelst.
Der offizielle Titel lautet "Date and Time on the Internet: Timestamps." Worüber der RFC wirklich entscheidet: eine eindeutige Art, einen Moment aufzuschreiben, etwa 2026-07-05T14:30:00Z, die Maschinen in jedem Land exakt gleich lesen.
- Status
- Proposed Standard
- Aktualisiert durch
- RFC 9557
Geschrieben von Noel Lang · IT-Trainer
Kurzfassung
RFC 3339 ist das Timestamp-Format des Internets. Es legt eine strikte, eindeutige Art fest, Datum und Zeit zu schreiben, etwa 2026-07-05T14:30:00Z, als eng gefasstes Profil von ISO 8601 mit einem Pflicht-Offset zu UTC. Es ist das, was die meisten JSON-APIs, Logs und Datenbanken meinen, wenn sie “ISO-Timestamp” sagen, denn es entfernt die Mehrdeutigkeiten, die volles ISO 8601 noch erlaubt.
Welches Problem er löst
Daten sind die Stelle, an der Systeme sich leise verraten. Ist 03/04/2026 März oder April? Meint ein nacktes 14:30 die Uhr des Servers, die des Nutzers oder UTC? Jahrzehntelang schrieb jede Sprache, jede Datenbank und jedes Land Timestamps ein bisschen anders, und “ein bisschen” reicht, um einen Flug am falschen Tag zu buchen.
ISO 8601 war die internationale Antwort, und sie half. Aber es ist ein großer Standard mit vielen optionalen Formen: Wochennummern, Tag-im-Jahr-Zählungen, fehlende Trennzeichen, weglassbare Offsets. Zwei Systeme können beide perfekt gültiges ISO 8601 sein und sich trotzdem uneins sein, wie derselbe Moment zu schreiben ist, ein Parser muss also weiter raten.
Der Zug von RFC 3339 ist Subtraktion. Er nimmt ISO 8601 und wirft fast jede Option weg, es bleibt eine starre Form: vierstelliges Jahr, Bindestriche, ein wörtliches T, eine Zeit und ein UTC-Offset, der nie optional ist. Weil nichts zu raten übrig bleibt, kann ein Parser ein kurzer regulärer Ausdruck sein, und ein Timestamp übersteht den Weg von einem Handy in Osaka zu einem Server in Ohio, ohne die Bedeutung zu ändern. Diese Vorhersagbarkeit ist der ganze Grund, warum es zum Standard für APIs, Logs und alles wurde, wo ein Moment eine Maschine verlässt und auf einer anderen landet.
Die Analogie mit dem Passstempel
Stell dir einen Timestamp als Passstempel für einen Moment vor. Eine ins Tagebuch gekritzelte Notiz (“halb drei, Dienstag”) bedeutet dir etwas und sonst niemandem: kein Jahr, kein Ort, keine Möglichkeit zu prüfen. ISO 8601 ist das volle internationale Regelbuch für Stempel, dick genug, dass zwei Grenzposten ihm folgen und trotzdem unterschiedlich aussehende Stempel produzieren.
RFC 3339 ist das eine zugelassene Stempeldesign, auf das sich jeder Schalter einigt. Feste Felder, feste Reihenfolge und eine Pflichtzeile für die Zeitzone, denn ein Stempel, der nicht sagt, wo die Uhr stand, ist ein Stempel, dem du nicht trauen kannst. Das Z am Ende ist der Schalter, der “lies das gegen UTC” schreibt, die eine Uhr, die die ganze Welt teilt. Eine Zeit ohne Offset ist ein Moment ohne Land; RFC 3339 weigert sich, so einen auszustellen.
Ein Timestamp, jedes Feld beschriftet
Das ist die Form, auf der RFC 3339 besteht. Neun Felder, immer dieselbe Reihenfolge, immer mit den Trennzeichen. Das einzig optionale Stück ist der Sekundenbruchteil; der Offset am Ende ist nie optional.
Das Format, Feld für Feld
Die Grammatik in Abschnitt 5.6 ist nur ein Dutzend Zeilen, und das meiste hast du oben schon gelesen. Ein paar Felder verdienen je einen Satz, denn das sind genau die Stellen, an denen Leute danebengreifen.
Das Jahr hat immer vier Ziffern. RFC 3339 widmet einen ganzen kurzen Abschnitt (Abschnitt 3) dem Verbot zweistelliger Jahre, ein kleines dauerhaftes Denkmal für die Y2K-Panik. Monat und Tag sind zweistellig mit den offensichtlichen Bereichen, und ja, der Tag wird gegen den Monat geprüft, 2026-02-30 ist also kein Datum.
Das T ist ein wörtlicher Buchstabe, der Datum und Zeit verbindet. Eine Anmerkung erlaubt stattdessen ein Leerzeichen zur besseren Lesbarkeit (genau das macht date --rfc-3339), und sowohl T als auch Z dürfen klein geschrieben werden. 2026-07-05t14:30:00z ist also legal, wenn auch etwas verwünscht.
Der Sekundenbruchteil ist ein Punkt gefolgt von beliebig vielen Ziffern: Millisekunden, Mikrosekunden, Nanosekunden, was deine Uhr eben liefert. RFC 3339 legt keine Länge fest, ein Parser sollte also 2026-07-05T14:30:00.5Z und ...00.123456789Z gleichermaßen akzeptieren.
Das Z bedeutet einen Null-Offset zu UTC. Die Spec selbst merkt an, es werde “oft Zulu gesprochen”, aus dem ICAO-Buchstabieralphabet, weshalb Luftfahrt- und Ops-Leute laut “vierzehn Uhr dreißig Zulu” sagen. Z ist Kurzform für +00:00.
Zwei wirklich überraschende Ecken. Sekunden können 60 sein: 1990-12-31T23:59:60Z ist ein echter, legaler Timestamp und markiert eine Schaltsekunde, den zusätzlichen Tick, der gelegentlich am Ende von Juni oder Dezember eingefügt wird, um Atomuhren mit der leicht unregelmäßigen Erddrehung im Takt zu halten. Und der Offset -00:00 ist nicht dasselbe wie +00:00: RFC 3339 definiert die negative Null als “wir kennen die UTC-Zeit, aber den lokalen Offset ehrlich nicht”, ein stilles, ehrliches Schulterzucken, das ISO 8601 dich nicht einmal hinschreiben lässt.
Was der RFC wirklich sagt
Das Original ist zehn Seiten lang und ungewöhnlich angenehm zu lesen. Die Landkarte, falls du vorbeischauen willst:
| Abschnitt | In einfachen Worten |
|---|---|
| 1 · Introduction | Warum ein einziges, striktes Timestamp-Format überhaupt aufzuschreiben lohnt: das Internet ist global, und Daten sind die Stelle, an der Systeme leise uneins werden. |
| 2 · Definitions | Das Vokabular: UTC, die Bedeutung von Z (und warum man es "Zulu" spricht), was ein Offset ist. Kurz und lesenswert. |
| 3 · Two digit years | Ein Einzeiler-Verbot: nein. Vier Ziffern, immer. Das Narbengewebe von Y2K, dauerhaft gemacht. |
| 4 · Local time | Offsets, der Trick für den unbekannten Offset (-00:00) und warum der Standard dich zu UTC drängt. |
| 5 · Date and time format | Das Herzstück: die ABNF-Grammatik, der Sekundenbruchteil, die Schaltsekunde und die Anmerkungen zu Kleinschreibung und Leerzeichen-Trenner. |
| Appendices | Die ISO-8601-Grammatik zum Vergleich, plus durchgerechnete Beispiele samt Schaltsekunde. Praktisch, wenn du mit jemandem diskutierst. |
RFC 3339 vs. ISO 8601, der Streit, der nie endet
Das ist die Frage, die alle wirklich in die Suchmaske tippen, also hier die ehrliche Antwort: RFC 3339 ist weder eine Teilmenge noch eine Obermenge von ISO 8601. Sie überlappen stark, und die meisten Timestamps, die dir begegnen, sind unter beiden gültig, aber jeder erlaubt etwas, das der andere nicht erlaubt.
ISO 8601 ist der ausufernde Elternteil. Es erlaubt Wochendaten (2026-W27), Ordinaldaten (2026-186), ein trennzeichenfreies Basisformat (20260705T143000Z) und, entscheidend, Zeiten ganz ohne Offset. RFC 3339 verbietet jedes einzelne davon, und das ist der ganze Punkt: weniger Formen, kein Raten.
In die andere Richtung erlaubt RFC 3339 -00:00 mit seiner speziellen “Offset unbekannt”-Bedeutung, und ISO 8601 verbietet einen negativen Null-Offset schlicht. Ein gültiger RFC-3339-Timestamp kann also ungültiges ISO 8601 sein. Genau dieser eine Fall ist der Grund, warum sorgfältige Leute “Profil von” statt “Teilmenge von” sagen.
Wo sich die beiden Formate überlappen
Die meisten echten Timestamps leben in der Mitte. Die Ränder sind die Stellen, an denen die zwei Standards leise uneins sind, und woher die “3339 vs. 8601”-Streits kommen.
Die Unterschiede, Regel für Regel
Dieselbe Idee wie das Diagramm, aber als Checkliste, die du in ein Code-Review kopieren kannst:
| Regel | RFC 3339 vs. ISO 8601 |
|---|---|
| Vierstelliges Jahr | Beide nutzen vier Ziffern. ISO 8601 erlaubt zusätzlich erweiterte Jahre wie +002026 nach vorheriger Absprache; RFC 3339 nicht. |
| UTC-Offset | RFC 3339 verlangt ihn. ISO 8601 macht ihn optional, was genau die Mehrdeutigkeit ist, gegen die 3339 existiert. |
| Datum/Zeit-Trenner | Beide nutzen ein wörtliches T. Beide erlauben auch ein Leerzeichen, RFC 3339 per ausdrücklicher Anmerkung, ISO 8601 nur "nach gegenseitiger Absprache". |
| Wochendaten (2026-W27) | Nur ISO 8601. RFC 3339 kennt nichts außer schlichten Jahr-Monat-Tag-Kalenderdaten. |
| Ordinaldaten (2026-186) | Nur ISO 8601. Die Zählung nach Tag-im-Jahr ist nicht Teil der RFC-3339-Grammatik. |
| Basisformat (20260705) | Nur ISO 8601. RFC 3339 behält Bindestriche und Doppelpunkte immer, damit Maschinen nie raten müssen, wo ein Feld endet. |
| Negativer Null-Offset (-00:00) | Nur RFC 3339. Er bedeutet "UTC bekannt, lokaler Offset unbekannt". ISO 8601 verbietet einen negativen Null-Offset rundheraus. |
Was wo gültig ist
Konkrete Strings, gegen die Grammatik geprüft. Das ist die Tabelle, die du behältst, wenn jemand darauf besteht, sein Timestamp sei in Ordnung:
| So geschrieben | Gültig wo |
|---|---|
| 2026-07-05T14:30:00Z | In beiden gültig. Die kanonische Form: UTC, Z als Null-Offset. |
| 2026-07-05T16:30:00+02:00 | In beiden gültig. Derselbe Moment wie die Zeile darüber, in Berliner Ortszeit geschrieben. |
| 2026-07-05 14:30:00Z | RFC 3339 akzeptiert das Leerzeichen (per Anmerkung). ISO 8601 nur nach Absprache. Genau das druckt date --rfc-3339. |
| 2026-07-05T14:30:00 | Nur ISO 8601. Kein Offset, also lehnt RFC 3339 ab: ist das London oder Tokio? |
| 2026-W27-1 | Nur ISO 8601. Ein Wochendatum (Montag der Woche 27). RFC 3339 weiß nicht, was eine Wochennummer ist. |
| 2026-07-05T14:30:00-00:00 | Nur RFC 3339. UTC ist bekannt, der lokale Offset bewusst unbekannt. ISO 8601 verbietet die negative Null. |
Ausprobieren: Ist dieser Timestamp gültiges RFC 3339?
Füg einen beliebigen Timestamp ein. Wir sagen dir, ob er striktes RFC 3339 ist, nur das weitere ISO 8601 oder schlicht kaputt, und schlüsseln jedes Feld auf.
Was Leute falsch verstehen
-
"RFC 3339 ist einfach ISO 8601."
Fast, aber das Gleichheitszeichen ist falsch. RFC 3339 ist ein striktes Profil: es behält eine kleine, sichere Scheibe von ISO 8601 und schraubt eine eigene Regel dran. ISO 8601 lässt dich Wochendaten, Ordinaldaten und Zeiten ohne Offset schreiben; RFC 3339 verbietet alle drei. Gleichzeitig erlaubt RFC 3339 -00:00, was ISO 8601 nicht tut. Keins ist eine saubere Teilmenge des anderen, "dasselbe wie" scheitert also in beide Richtungen.
-
"Z und +00:00 sind identisch."
Für den Moment ja: beide sind Null-Offset zu UTC. Die Falle ist -00:00. RFC 3339 definiert es als "die UTC-Zeit ist bekannt, aber der lokale Offset nicht". Z und +00:00 setzen also UTC als gemeinten Bezug, während -00:00 still zugibt, nicht zu wissen, wo auf der Erde das passiert ist. Gleiche Zahlen, andere Bedeutung.
-
"Das T ist optional und 23:59:60 ist ein Tippfehler."
Zwei Mythen in einem. Das T gehört zur Grammatik; du darfst es nur gegen ein Leerzeichen tauschen, weil eine Anmerkung es ausdrücklich erlaubt, und es darf klein sein. Und 23:59:60 ist kein Bug: Sekunden laufen legal bis 60 für eine Schaltsekunde, den zusätzlichen Tick, den die Welt gelegentlich am Ende von Juni oder Dezember einschiebt, um Uhren mit der Erdrotation abzugleichen.
-
"Ein Unix-Timestamp ist RFC 3339."
Nein. Ein Unix-Timestamp ist eine Ganzzahl, Sekunden seit dem 1. Januar 1970, etwa 1783000200. RFC 3339 ist lesbarer Text, 2026-07-05T14:30:00Z. Beide benennen einen Moment, aber der eine ist eine Zahl, der andere ein String. Man rechnet um, man benennt nicht bloß neu.
Wo dir dieses Format begegnet
Du hast heute mit ziemlicher Sicherheit hundert RFC-3339-Timestamps gelesen, ohne es zu merken. Ein Feldführer:
| Du siehst | Du schaust auf |
|---|---|
| Ein JSON-API-Feld | "createdAt": "2026-07-05T14:30:00Z". JSON hat keinen Datumstyp, also serialisieren REST- und GraphQL-APIs Momente fast durchweg als RFC-3339-Strings. |
| Kubernetes- und Cloud-Logs | Jede kubectl-Log-Zeile und die meisten strukturierten Logger stempeln Ereignisse in RFC 3339, damit Zeitachsen verschiedener Maschinen zusammenpassen. |
| date --rfc-3339=seconds | GNU coreutils hat ein eigenes Flag. Es druckt 2026-07-05 14:30:00+00:00, mit dem Leerzeichen-Trenner, den die Anmerkung erlaubt. |
| JavaScript toISOString() | new Date().toISOString() liefert 2026-07-05T14:30:00.000Z. Es ist RFC 3339 by construction, weshalb die beiden Namen im Alltag verschwimmen. |
| Datenbanken (Postgres, SQLite) | timestamptz-Spalten werden als RFC 3339 dargestellt, und es ist das sicherste Textformat, um sie ohne Locale-Überraschung zurückzugeben. |
| Atom-Feeds, TOML, OpenAPI | Alle drei verweisen für ihre Datum-Zeit-Werte auf RFC 3339, einer der leisen Gründe, warum es zum Standard wurde. |
Fragen, die wirklich gestellt werden
Ist RFC 3339 dasselbe wie ISO 8601? +
Nicht ganz. RFC 3339 ist ein striktes Profil von ISO 8601: eine kleine, eindeutige Teilmenge mit ein paar eigenen Regeln. Die meisten RFC-3339-Timestamps sind gültiges ISO 8601, aber ISO 8601 erlaubt auch Formen, die RFC 3339 verbietet (Wochendaten, Ordinaldaten, fehlende Offsets), und RFC 3339 erlaubt -00:00, was ISO 8601 nicht tut. Keins ist also vollständig im anderen enthalten.
Was ist ein Beispiel für einen RFC-3339-Timestamp? +
2026-07-05T14:30:00Z bedeutet 5. Juli 2026, 14:30:00 UTC. Das T trennt Datum und Zeit, das Z steht für Zulu, einen Null-Offset zu UTC. Ein Offset kann das Z ersetzen: 2026-07-05T16:30:00+02:00 ist derselbe Moment in mitteleuropäischer Sommerzeit.
Unterstützt RFC 3339 Millisekunden? +
Ja. Ein Sekundenbruchteil ist direkt nach den Sekunden erlaubt, mit beliebig vielen Ziffern: 2026-07-05T14:30:00.123Z sind 123 Millisekunden, 2026-07-05T14:30:00.123456Z sind Mikrosekunden. RFC 3339 legt die Länge nicht fest, Parser sollten also jede Ziffernzahl akzeptieren.
Ist das T in RFC 3339 Pflicht? +
In der Kern-Grammatik ja: Datum und Zeit werden durch ein wörtliches T verbunden. Eine Anmerkung erlaubt aber ein Leerzeichen zur besseren Lesbarkeit, also ist 2026-07-05 14:30:00Z ebenfalls gültig. T und Z dürfen klein geschrieben werden (t und z). Das Einzige, was du nicht weglassen darfst, ist der Offset.
Was ist der Unterschied zwischen Z und +00:00? +
Für den eigentlichen Moment nichts: beide sind Null-Offset zu UTC. Der feine Fall ist -00:00, das RFC 3339 als 'die UTC-Zeit ist bekannt, aber der lokale Offset nicht' definiert. Z und +00:00 setzen UTC als Bezugspunkt; -00:00 sagt still, dass der Offset unbekannt ist.
Ist ein Unix-Timestamp ein RFC-3339-Timestamp? +
Nein. Ein Unix-Timestamp ist eine einzelne Ganzzahl, Sekunden seit 1970 (etwa 1783000200). RFC 3339 ist lesbarer Text (2026-07-05T14:30:00Z). Beide beschreiben dasselbe, einen Moment, aber sie sind kein austauschbarer Text; man rechnet zwischen ihnen um.
Wie bekomme ich einen RFC-3339-Timestamp im Code? +
In JavaScript liefert new Date().toISOString() 2026-07-05T14:30:00.000Z, gültiges RFC 3339. In Python gibt datetime.now(timezone.utc).isoformat() 2026-07-05T14:30:00+00:00. In der Shell druckt date --rfc-3339=seconds 2026-07-05 14:30:00+00:00 mit Leerzeichen als Trenner.
Verweise hierher
Andere Erklärseiten auf dieser Website, die auf diesen RFC zurückverweisen:
Wie RFC 3339 zusammenhängt
Womit es zusammenspielt
-
RFC 2119 · geschrieben in
Die MUST/SHOULD-Schlüsselwörter
Die Grammatik von RFC 3339 wird mit den Anforderungswörtern (MUST, SHOULD, MAY) durchgesetzt, die hier definiert sind. Wenn die Spec sagt, der Offset MUSS da sein, gibt dieser RFC dem Wort sein Gewicht.
-
RFC 8259 · wo es lebt
JSON hat keinen Datumstyp
JSON kennt nur Strings und Zahlen, nie Daten. Also stecken APIs den Moment in einen String, und der String, auf den sich fast alle einigten, ist RFC 3339. Deshalb meint "ISO-Datum" in einem JSON-Payload fast immer genau das.
-
RFC 9557 · aktualisiert durch
Die Fortsetzung von 2024 (IXDTF)
<span class="text-neutral-500">(2024)</span> erweitert das Format um optionale Klammer-Tags, sodass du eine IANA-Zeitzone anhängen kannst, etwa <span class="font-mono text-sm">2026-07-05T14:30:00+02:00[Europe/Berlin]</span>. Alte Parser lesen weiterhin den vorderen Teil, neue lernen Kalender und Zone.
Seine Gegenstücke
-
RFC 5322 · das andere Datumsformat
Wie E-Mail das Datum schreibt
Öffne einen beliebigen E-Mail-Header, und die Date-Zeile sieht völlig anders aus: <span class="font-mono text-sm">Tue, 05 Jul 2026 14:30:00 +0200</span>. Dieses menschenfreundliche Format steht in RFC 5322, und es ist der Grund, warum Mail und APIs nie denselben Datums-Parser teilen.
-
RFC 9110 · HTTPs Datumsformat
Wie HTTP das Datum schreibt
HTTP-Header wie <span class="font-mono text-sm">Date</span> und <span class="font-mono text-sm">Last-Modified</span> nutzen ein drittes Format, <span class="font-mono text-sm">Tue, 05 Jul 2026 14:30:00 GMT</span>, festgelegt in RFC 9110. Drei Internet-Datumsformate, drei Gremien, ein müder Entwickler.