Vergleich von RFC 3339 und ISO 8601

 (ijmacd.github.io)
3 Punkte von GN⁺ 2023-09-01 | 1 Kommentare | Auf WhatsApp teilen
  • Bei der Darstellung von Datum und Uhrzeit ist RFC 3339 eher eine enge Teilmenge, die sich für Web und Internet leicht verwenden lässt, während ISO 8601-1:2019 einen deutlich breiteren Satz von Formaten umfasst
  • Der Vergleich ist auf ISO 8601-1:2019 beschränkt; zusätzliche Darstellungen aus ISO 8601-2:2019 wie Jahreszeiten, Mengen, Unsicherheitsqualifizierer oder Datumsarithmetik sind in der Tabelle noch nicht berücksichtigt
  • Beide Standards behandeln grundlegende Datums- und Zeitformate, die weit verbreitet sind, etwa 2026-06-26, 14:08:00Z, 2026-06-26T14:08:00Z und Offsets wie +00:00
  • ISO 8601 umfasst außerdem Jahrhunderte, Jahrzehnte, Ordinaldaten, Wochendaten, verkürzte Zeiten, Komma als Dezimaltrennzeichen, Zeitspannen (P1Y) und Bereiche (2026-06-26/P1Y), während RFC 3339 in der Tabelle meist ausgeschlossen ist
  • Bei der Date-Time-Notation sind Unterschiede beim T-Trennzeichen, bei Groß-/Kleinschreibung und bei Offsets wie -00:00 Punkte, die in der Praxis über Parser-Kompatibilität entscheiden

Vergleichsumfang und Annahmen

  • Die Formattabelle ist keine vollständige Liste
  • Der betrachtete Standard ist ISO 8601-1:2019
    • Es gibt wichtige Unterschiede zu früheren Ausgaben und Entwürfen
  • ISO 8601-2:2019 enthält zusätzliche Darstellungen, die auf dieser Seite aber noch nicht berücksichtigt sind
    • unterjährige Gruppen, etwa Jahreszeiten
    • Gruppierungseinheiten
    • Mengen
    • Unsicherheitsqualifizierer
    • Datumsarithmetik
  • RFC 3339 schlägt in einem nachgeordneten Standard vor, T durch andere Zeichen zu ersetzen, liefert als Beispiel jedoch nur das Leerzeichen
  • Jeder Standard definiert Formate für bestimmte Zwecke; andere Formate werden nicht empfohlen

ISO 8601 ist bei Datumsangaben breiter

  • Sowohl RFC 3339 als auch ISO 8601 unterstützen Jahr-Monat-Tag-Daten wie 2026-06-26
  • ISO 8601 deckt mehr Datumsdarstellungen ab als RFC 3339
    • Jahrhundert: 20
    • Jahrzehnt: 202
    • Jahr: 2026
    • Jahr-Monat: 2026-06
    • Ordinaldatum: 2026-177
    • Wochendatum: 2026-W26, 2026-W26-5
    • Grundformat: 20260626, 2026177, 2026W26, 2026W265
  • In der Tabelle erlaubt RFC 3339 diese ISO-spezifischen Datumsformate nicht

Unterschiede bei Zeitangaben

  • Beide Standards erlauben Zeiten mit Sekundenauflösung und Zeitzonen-Offset wie 14:08:00Z, 14:08:00+00:00 und 14:08:00.372+00:00
  • RFC 3339 unterscheidet nicht zwischen Groß- und Kleinschreibung, daher können T und Z auch als t bzw. z geschrieben werden
    • Auch frühere Ausgaben von ISO 8601 unterschieden hier nicht nach Groß- und Kleinschreibung
  • ISO 8601 erlaubt bei der kleinsten Zeiteinheit einen Dezimalanteil
    • In der Tabelle werden meist Beispiele mit einer Nachkommastelle gezeigt, der Standard erlaubt aber beliebige Genauigkeit
    • Sowohl Komma als auch Punkt sind als Dezimaltrennzeichen zulässig und in allen Formaten austauschbar
  • ISO 8601-1:2019 erlaubt das Weglassen von T bei alleinstehenden Zeitangaben, sofern keine Mehrdeutigkeit entsteht
  • ISO 8601 unterstützt verkürzte, grundlegende und Zeitformate mit Komma-Dezimalen wie 14, 14:08, 14:08:00, 140800, T14:08:00, 14:08:00,372
  • RFC 3339 erlaubt Offsets wie -00:00 in 14:08:00-00:00, während ISO 8601 dies in der Tabelle nicht erlaubt

T und Trennzeichen in Date-Time

  • Sowohl RFC 3339 als auch ISO 8601 erlauben Date-Time-Angaben wie 2026-06-26T14:08:00Z und 2026-06-26T14:08:00+00:00
  • In der Date-Time-Darstellung von ISO 8601 ist T immer erforderlich
    • Frühere Ausgaben erlaubten auch das Weglassen von T in Date-Time
    • Auch in früheren Ausgaben war das Einfügen alternativer Trennzeichen wie Leerzeichen oder Unterstrich nicht erlaubt
  • In der Tabelle erlaubt RFC 3339 die folgenden Date-Time-Varianten
    • kleingeschriebenes t und z: 2026-06-26t14:08:00z
    • Leerzeichen als Trennzeichen: 2026-06-26 14:08:00Z
    • Unterstrich als Trennzeichen: 2026-06-26_14:08:00Z
    • Offset -00:00: 2026-06-26T14:08:00-00:00
  • ISO 8601 behandelt verkürzte Date-Time-Angaben sowie Date-Time auf Basis von Ordinal- und Wochendaten wie 2026-06-26T14, 2026-06-26T14:08, 2026-06-26T14:08:00, 2026-177T14:08, 2026-W26-5T14:08

Zeitspannen und Bereiche liegen im Schwerpunkt von ISO 8601

  • In der Tabelle sind Zeitspannen-Formate (Periods) nur für ISO 8601 markiert
    • Beispiele: P1Y, P1M, P1W, P1D
    • Mit Zeitanteil: PT1H, PT1M, PT1S
    • Kombinationen: P1Y1M1DT1H1M1S
    • Mit Dezimalen: P1.5Y, P1,5W, PT1.5S
  • Auch Bereichsformate (Ranges) sind nur für ISO 8601 markiert
    • Datum und Zeitspanne: 2026-06-26/P1Y
    • Datum und Datum: 2026-06-26/2026-06-26
    • Zeitspanne und Datum: P1Y/2026-06-26
    • Date-Time und Zeitspanne: 2026-06-26T14:08/P1DT1H
    • Wiederholungsbereiche: R/2026-06-26/P1Y, R10/2026-06-26/P1Y

Formatschlüssel und Testwerkzeuge

  • Die Formattabelle verwendet Formatschlüssel wie %Y, %M, %D, %h, %m, %s
    • %Y: Year
    • %M: Month
    • %D: Day
    • %V: Week Year
    • %W: Week
    • %w: Week Day
    • %O: Ordinal Day
    • %h: Hour
    • %m: Minute
    • %s: Second
    • %u: Microsecond
    • %n: Nanosecond
    • %Z: Zeitzonenstunde einschließlich + oder -
    • %z: Zeitzonenminute
  • Der Formatprüfer überprüft nur, ob ein Eingabeformat einem Format aus der Tabelle entspricht
    • Er prüft nicht alle möglichen Formate
  • ISO 8601 as a Service ist ein Dienst für Beta-Tests
    • Derzeit werden nur Date, Time und DateTime unterstützt
    • Period und Range werden nicht unterstützt
  • Der Quellcode ist auf GitHub öffentlich verfügbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-01
Meinungen auf Hacker News

  • Es ist seltsam, dass es keine Möglichkeit gibt, ein zukünftiges Datum/eine zukünftige Uhrzeit bezogen auf eine bestimmte Zeitzone anzugeben. Man könnte zum Beispiel am 1. Juli 2030 um 18 Uhr Ortszeit London ein Meeting planen wollen; egal wie sich die britischen Zeitzonenregeln bis dahin ändern, es sollte „18 Uhr in London“ bleiben.
    Derzeit nutzt das Vereinigte Königreich ungefähr von November bis März Z+00:00 und von April bis Oktober Sommerzeit Z+01:00[0], könnte aber vor 2030 Mitteleuropäische Zeit[1] einführen, British Double Summer Time[2] erneut ausprobieren oder die Sommerzeit abschaffen. Dadurch kann dasselbe „18 Uhr“ bezogen auf eine bestimmte Epoch-Zeit stark variieren.
    Ich möchte in ein Kalenderereignis „18 Uhr nach Londoner Zeit zu diesem Zeitpunkt“ eintragen, aber es gibt keine standardisierte, interoperable Möglichkeit, 2030-07-01 18:00:00 Europe/London auszudrücken.
    [0] https://en.wikipedia.org/wiki/British_Summer_Time
    [1] https://en.wikipedia.org/wiki/Central_European_Time
    [2] https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of...

    • Für ein solches Format gibt es einen Entwurf namens IXDTF (Internet Extended Date/Time Format)[0]. Man kann an einen RFC-3339-String in eckigen Klammern einen Zeitzonennamen als tz anhängen; um eine lokale Uhrzeit auszudrücken, muss außerdem ein geschätzter UTC-Offset angegeben werden.
      Zum Beispiel wird aus 2030-07-01 18:00:00 Europe/London dann 2030-07-01T18:00:00+01:00[Europe/London]. Wenn sich die britischen Regeln bis dahin ändern, wird der Timestamp „inkonsistent“, und die Anwendung entscheidet, wie sie damit umgeht. Setzt man jedoch ein ! vor den Zeitzonennamen in den eckigen Klammern, darf der UTC-Offset nicht blind übernommen werden; das Problem muss erkannt werden.
      Dieses erweiterte Timestamp-Format wird auch in der vorgeschlagenen Temporal-Bibliothek[1] von JavaScript verwendet; die Parsing-Funktion ZonedDateTime.from()[2] erlaubt es, bei inkonsistenten Timestamps über die Option offset zu steuern, welche Seite Vorrang hat. Auch das Weglassen des UTC-Offsets und die alleinige Angabe der Zeitzone werden unterstützt, allerdings mit dem Hinweis, dass die bei einer Sommerzeitumstellung wiederholte Stunde mehrdeutig ist.
      [0] https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...
      [1] https://tc39.es/proposal-temporal/docs/strings.html#iana-tim...
      [2] https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu...
    • Eigentlich scheint man noch spezifischere Informationen als nur die Zeitzone zu brauchen. Angenommen, man möchte sich nicht in London, sondern am 1. Juli 2030 um 18 Uhr in Glasgow, Schottland, treffen; derzeit liegt Glasgow in der Zeitzone Europe/London.
      Aber es ist nicht völlig unvorstellbar, dass Schottland bis dahin ein weiteres Unabhängigkeitsreferendum abhält und der Mitteleuropäischen Zeit beitritt oder eine Scottish Standard Time einführt.
    • Die Falle bei solchen Ausdrücken ist, dass mehrdeutige oder unmögliche Timestamps entstehen. 2023-11-05 01:30:00 America/New_York kann einer von zwei verschiedenen Zeitpunkten sein.
      In Kalendern ist „dieselbe Uhrzeit an der Wanduhr“ meistens die gewünschte Bedeutung und daher sinnvoll, aber es gibt UI-Schwierigkeiten beim Umgang mit ungewöhnlichen Uhrzeiten, und man möchte vielleicht eine Möglichkeit zur Auflösung der Mehrdeutigkeit in die Syntax aufnehmen. Zum Glück finden solche Umstellungen meist mitten in der Nacht statt, aber ich habe so etwas im echten Arbeitsalltag schon gesehen.
      Wenn man jemanden aus einer Zeitzone ohne Sommerzeit einlädt, verschiebt sich die Uhrzeit in dessen Kalender, und internationale Kolleginnen und Kollegen müssen das manchmal hinnehmen.
    • In der Kalenderwelt wird das in iCal bereits unterstützt. Ein Datum-Uhrzeit-Wert ohne Zeitzone bedeutet nur die lokale Uhrzeit[0].
      [0]: https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5
    • Die benötigten Informationen sind drei Dinge: Datum, Ort und lokale Uhrzeit. Was man tatsächlich will, ist möglicherweise gar keine Zeitzone. Man muss überlegen, was passieren soll, wenn ein bestimmter Ort, der nicht London ist, in eine andere Zeitzone wechselt.
      Gängige Datum-Uhrzeit-Formate wurden dafür entwickelt, einen bestimmten Zeitpunkt auszudrücken, aber in diesem Fall gibt es einen solchen bestimmten Zeitpunkt noch nicht. Es kommt häufig vor, dass Datums-/Zeitangaben nichttriviale Strukturen haben: ein Meeting am letzten Freitag jedes Monats, ein monatliches Meeting, das am 31. Januar beginnt, oder zwei Tage vor Quartalsende.
      Ein Standard, der alle denkbaren Fälle abdecken soll, dürfte schnell komplex werden. Wenn einfache Daten, Uhrzeiten und Zeitpunkte nicht ausreichen, bleibt wohl nur, eine eigene Struktur zu schaffen, die alle benötigten Elemente enthält.

  • Da die ISO-Spezifikation nicht kostenlos verfügbar ist, ist es meist besser, sich an den RFC zu halten; zudem basieren viele Open-Source-Implementierungen auf Entwürfen, sodass man sie nicht wirklich als vollständig Open-Source-freundlich bezeichnen kann. Auch für Open-Source-Entwickler ist das eine große Belastung.
    Wenn man etwas baut, das mit zukünftigen Datumsangaben umgeht, möchte man fast immer Wanduhrzeit + Ort speichern. Leider gibt es dafür keinen Standard. In Europa und den USA sind Zeitzonen recht stabil, sodass man das vielleicht nicht so stark merkt, aber in vielen Regionen ändern sich Zeitzonen häufig, weshalb das Speichern eines Offsets nicht stabil ist.
    5. Juni 2026, 13:30 Wanduhrzeit, Paris ist das, was die meisten Menschen meinen; je nachdem, wie die EU mit der Sommerzeit verfährt, kann das UTC+2 oder UTC+1 sein. Wenn eine API vergangene Zeitpunkte behandelt, kann man einfach POSIX-Timestamps in Sekunden, Millisekunden, Mikrosekunden oder Nanosekunden verwenden.

    • iCalendar ist ein RFC-Standard dafür[1]. Allerdings haben bei Zeitumstellungen durch Sommerzeit manche Zeitpunkte zwei Darstellungen, und manche Zeitpunkte lassen sich in diesem Format gar nicht darstellen.
      iCal berücksichtigt auch nicht das Problem, dass ein Ort einer anderen Zeitzone neu zugeordnet wird. Außerdem enthält eine korrekte iCal-Datei alle Zeitzonendaten, auf die sie verweist, was umständlich ist, wenn man nur ein einzelnes Datum mit Uhrzeit ausgeben möchte.
      [1] https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.htm...
    • Es gibt einen Entwurfsstandard namens IXDTF, der RFC 3339 erweitert, indem er den IANA-Zeitzonennamen in eckige Klammern setzt: 2026-06-05T13:30+0200[Europe/Paris]
      https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...

  • Ein in Standards häufig ignorierter Teil ist die Darstellung von Dauern.
    Siehe 5.5.4.2 „Representation of time-interval by duration only“, Seite 21, in http://xml.coverpages.org/ISO-FDIS-8601.pdf. Es wäre gut, wenn JSON-Parser in statischen Sprachen ein Feld als Dauer definieren und in ein gültiges Format serialisieren könnten.
    Ein Beispiel für einen Vorschlag in Crystal findet sich hier: https://github.com/crystal-lang/crystal/issues/11942
    Zum Beispiel werden 15 Tage, 5 Stunden und 20 Sekunden zu P15DT5H0M20S, 7 Wochen zu P7W.

    • Alternativ kann man auch auf die Definition von duration in der ABNF aus Anhang A von RFC 3339 verweisen.
    • Ich verstehe nicht, warum man strukturierbare Daten als String-Format haben möchte.
      Wenn man zum Beispiel "duration": { "days": 15, "hours": 5, "seconds": 20 } schreibt, muss der JSON-Parser die Bedeutung der Daten nicht verstehen; das kann ein Eingabevalidator übernehmen. Unabhängig davon, wie JSON diese Daten darstellt, braucht man ohnehin einen potenziell fehleranfälligen Umwandlungsschritt.

  • Es ist „witzig“, dass RFC 3339 und ISO 8601 viele redundante Datums-/Uhrzeitformate mit überlappendem Zweck enthalten, aber beide das in allen Systemen am häufigsten verwendete und völlig naheliegende 2023-09-01 15:30:59 nicht enthalten.
    Außerdem sind beide Standards sehr unklar darin, wie Daten vor Christus sowie Daten nach 9999-12-31 oder vor -9999-01-01 dargestellt werden sollen, und gängige Bibliotheken können damit meist überhaupt nicht umgehen. Selbst wenn sie es tun, ist das Verhalten von 00-01-01 praktisch undefiniert.
    Der gregorianische Kalender ist merkwürdig, weil auf 1 v. Chr. direkt 1 n. Chr. folgt, und außerhalb spezialisierter astronomischer Software kann fast keine Software Bereiche weit außerhalb der nahen zukünftigen Unix-Zeit korrekt behandeln. Selbst Dinge, die man problemlos als Strings speichern könnte, etwa die Lebensdaten von Kaiser Augustus, sollten im Standard klar definiert sein.

    • ISO 8601 erlaubt dieses Format bei gegenseitiger Vereinbarung. „Gegenseitige Vereinbarung“ klingt hochtrabend, aber es reicht eine einfache Einschränkung wie bei ISO 8601, dass T durch ein Leerzeichen ersetzt werden darf. RFC 3339 macht Ähnliches, nur deutlich umständlicher.
      Ob 2023-09-01 15:30:59 wirklich das am häufigsten verwendete Datums-/Uhrzeitformat ist, ist schwer zu sagen. Die meistverwendete Sprache ist Chinesisch, und eigene Trennzeichen wie 2023年9月1日 sind verbreitet.
      ISO 8601 erlaubt bei gegenseitiger Vereinbarung auch Jahre vor 1582 oder nach 9999. Wenn sie nicht in vier Stellen passen, muss ein einzelnes Vorzeichenzeichen vorangestellt werden. Solche Daten werden im Allgemeinen nicht unterstützt, weil man mit ihnen nur wenig Sinnvolles tun kann, aber insbesondere bei unabhängig von C implementierten Bibliotheken habe ich durchaus gesehen, dass sie geparst werden.
      00-01-01 ist als 1. Januar 1 v. Chr. definiert. ISO 8601 stellt klar, dass Jahreszahlen dem proleptischen gregorianischen Kalender folgen und damit bis minus unendlich extrapoliert werden.
    • Das durch Leerzeichen getrennte Format ist viel besser lesbar. Nachdem ich fast 20 Jahre lang die Standards eingehalten habe, habe ich in letzter Zeit angefangen, beide zugunsten des besseren Leerzeichenformats zu ignorieren.
      Ich verstehe, warum man ein Nicht-Leerzeichen brauchte, aber man hätte zumindest einen Unterstrich oder einen Punkt verwenden können. Und ich verstehe auch nicht, warum man bei einem String den Jahresbereich auf vier Stellen beschränkt und damit die Allgemeingültigkeit des Formats opfert.

  • Sechsstellige Jahreszahlen wirken wie eine Lösung für ein Problem, das in der Praxis nicht entstehen wird, nur um zukunftsorientiert zu erscheinen. Es ist kaum vorstellbar, dass heutige Technologie oder gesellschaftliche Normen 8000 Jahre fortbestehen.

    • Computer werden nicht nur für Dinge benutzt, die mit dem Heute zu tun haben. Wenn man zum Beispiel sehr lange Klimaberechnungen laufen lässt, könnte man Fehler wegen des Datums zwar einfach ignorieren, aber wäre es nicht besser, wenn sie gar nicht erst auftreten?
    • Ob fünf- oder siebenstellig: Man kann jede Stellenzahl verwenden, auf die sich beide Seiten vor Beginn der Kommunikation einigen können. Teil 2 des Standards enthält sogar ein Beispiel mit zehnstelligen Jahreszahlen.
    • Sechsstellige Jahreszahlen sind eine Lösung für ein Problem, das es schon heute gibt. Man denke an Geologen, die Kontinentalverschiebung simulieren.

  • Die Aussage, ISO 8601 verwende U+2010 HYPHEN und U+2212 MINUS und in Zeichensätzen ohne diese Zeichen müsse U+2D HYPHEN-MINUS verwendet werden, ist falsch.
    Tatsächlich legt ISO 8601 fest, dass, wenn der Zielzeichensatz auf ISO/IEC 646 basiert, in beiden Fällen das Hyphen-Minus-Zeichen zu verwenden ist. Unicode ist hier eindeutig eingeschlossen. Es gibt zwar eine gewisse Unschärfe, aber bei Unicode ist die Auslegung klar; es wirkt wie ein indirekter Weg, durch Festlegung des regulären Mappings von 646 die Kompatibilität mit anderen auf 646 basierenden Zeichensätzen sicherzustellen.

    • Der entsprechende Absatz steht in ISO 8601-1:2019 §3.2.1.
      Sinngemäß heißt es: „Alle Zeichen, die in Datums- und Zeitdarstellungen verwendet werden, gehören mit Ausnahme von ‘hyphen’, ‘minus’ und ‘plus-minus’ zum ISO/IEC-646-Repertoire. In Umgebungen, die ein auf ISO/IEC 646 basierendes Zeichenrepertoire verwenden, müssen ‘hyphen’ und ‘minus’ beide auf ‘hyphen-minus’ abgebildet werden.“
      Da Unicode auf ISO 8859 basiert und ISO 8859 wiederum auf ISO 646, scheint die Absicht für den Unicode-Zeichensatz tatsächlich zu sein, U+2D hyphen-minus zu verwenden.

  • Unter Windows stört es oft, dass der Doppelpunkt ein Sonderzeichen ist und es deshalb keine RFC-3339-konforme Möglichkeit gibt, Datum und Uhrzeit in Dateinamen zu verwenden.
    Es wäre schön, wenn man beim Datum Bindestriche verwenden und beim Zeitteil die Doppelpunkte weglassen könnte und trotzdem ISO 8601 einhielte. 20230831T1510-0500 zum Beispiel ist konform und kann in Dateinamen verwendet werden, 2023-08-31T1510-0500 und ähnliche Varianten dagegen nicht. Nebenbei: Die PowerShell-Funktion Get-Date versteht den ersten Zeitstempel ohne Bindestriche und Doppelpunkte nicht.

    • Das Entfernen der Doppelpunkte ist sicher und macht RFC-3339-Daten und -Datum-Uhrzeit-Angaben nicht mehrdeutig. Man kann die Doppelpunkte jederzeit verlustfrei wiederherstellen.
    • Ich wusste nicht, dass Windows dieses Problem hat. MacOS hat andere Probleme mit Doppelpunkten in Dateinamen. Wenn zwei der drei meistgenutzten Betriebssysteme dieses Problem haben, war das Design eindeutig nicht durchdacht genug.

  • Eine sehr gute Visualisierung zu diesem Thema.
    Beim Trennen von Datums- und Zeitteil bevorzuge ich Leerzeichen oder Unterstriche statt T, aber um Probleme mit Systemen zu vermeiden, die nur ISO 8601 verarbeiten, und aus Gründen der Konsistenz verwende ich meistens weiter T.

    • Ich bevorzuge T. Solche Strings wird man wohl kaum versehentlich anhand von T aufteilen.

  • Zwei Dinge würden mich interessieren. Erstens: Was ist die Begründung für sechsstellige Jahreszahlen? Kein heute entworfenes System wird doch in 100.000 Jahren noch existieren.
    Zweitens: ISO 8601 ist weit verbreitet, aber wird RFC 3339 in realen Systemen ebenfalls häufig genutzt und übernommen?

    • Wenn man sieht, wie lange es dauert, sich vollständig von alter Technik zu lösen, würde es mich nicht überraschen, wenn in 100.000 Jahren auf Quantencomputern x86 emuliert wird.
    • Wenn eine Bibliothek sagt, sie unterstütze ISO 8601, heißt das in 90 % der Fälle in Wirklichkeit nicht, dass sie auch die obskureren Teile von ISO 8601 implementiert.
    • Das offizielle time-Paket von Golang und Rusts Chrono haben eingebaute Werkzeuge für RFC 3339, aber nicht für RFC 8601.
      Soweit ich mich erinnere, hatte RFC 8601 Mehrdeutigkeitsprobleme, die RFC 3339 nicht hat, und Python hatte deswegen ebenfalls Probleme bei der Roundtrip-Konvertierung von Datumswerten.
    • Bei wissenschaftlichen Werkzeugen kann es durchaus sinnvoll sein, Daten in ferner Zukunft ausdrücken zu wollen.
    • Y10k (:

  • Es gibt kein Format, bei dem die Zeitzone als vier Ziffern ohne Doppelpunkt angegeben wird, aber date +%z gibt ±NNNN zurück.

    • Zum Glück gibt es %:z. Außerdem kann man date beibringen, standardmäßig so auszugeben: https://gist.github.com/d081dad407432d53172e30d0d35c39db
      $ date
      2023-08-31T11:15:00-07:00
    • ±NNNN ist ohne Doppelpunkt gültig, wenn es als Teil des „Basisformats“ verwendet wird. Das heißt, im gesamten Format dürfen weder Bindestriche noch Doppelpunkte vorkommen.
      Daher sind die folgenden beiden Angaben äquivalent und beide gültig:
      2023-09-01T09:40:01+08:00
      20230901T094001+0800