Zusammenfassung

  • RFC 9557 erweitert RFC 3339 um optionale Suffixe. Sie transportieren Zeitzonen- oder Kalenderkontext, nicht den tatsächlich eingesetzten Regelstand aller Systeme.
  • Z bedeutet nach der Aktualisierung: UTC-Zeitpunkt bekannt, lokaler Offset unbekannt. +00:00 behauptet dagegen ausdrücklich einen Offset von null.
  • Ein kritisches Suffix verlangt bei fehlender Unterstützung einen Stopp. Das Zeichen beweist nicht, dass Vermittler es erhielten oder die Zielanwendung es befolgte.

Ein Zeitstempel mit Offset und Zonennamen wirkt wie eine abgeschlossene Tatsache. Für Protokolle, Termine und Berechtigungen wird daraus schnell die Annahme, auch die Bedeutung sei abgeschlossen. RFC 9557 liefert mit IXDTF eine genauere Darstellung, hält aber die Grenze zur betrieblichen Entscheidung offen.

Das im April 2024 im Standards Track veröffentlichte Dokument aktualisiert RFC 3339. Der Basisteil beschreibt weiterhin einen auf UTC bezogenen Zeitpunkt. Eckige Klammern können zusätzlichen Interpretationskontext tragen. Sie nennen Regeln; sie konservieren nicht den Zustand jeder später ausführenden Umgebung.

Z ist kein Null-Offset-Beweis

RFC 9557 gibt Z dieselbe Bedeutung wie -00:00: Der UTC-Zeitpunkt ist bekannt, der lokale Offset nicht. +00:00 erklärt den Offset für null und kann UTC als bevorzugten Bezug ausdrücken. Beide Formen können denselben Zahlenwert ergeben und trotzdem unterschiedliche Herkunftsaussagen bewahren.

Normalisierung löscht diesen Unterschied leicht. Speichert eine Datenbank nur Epoch-Zeit oder schreibt ein Serialisierer alles als Z, ist später nicht mehr erkennbar, was der Erzeuger behauptete. Deshalb gehören Quellbytes, normalisierter Zeitpunkt und Parser-Version zusammen in den Beleg.

Ein Zonenname versioniert die Regeln nicht

[Europe/Berlin] verweist auf einen Regelsatz, enthält aber keine konkrete Ausgabe der IANA Time Zone Database. Politische Regeln ändern sich, TZDB-Releases erscheinen und Dienste aktualisieren zeitversetzt. Was beim Erzeuger konsistent war, kann beim Empfänger mit neueren Daten widersprüchlich sein.

IXDTF kann einen Konflikt zwischen numerischem Offset und Zone sichtbar machen. Es entscheidet im Allgemeinen nicht, welche Seite die Absicht trägt. Bei einem zukünftigen Termin muss die Anwendung wissen, ob der absolute Zeitpunkt oder die örtliche Uhrzeit erhalten bleiben soll. Dazu braucht sie Intentionsart, TZDB-Version, Neuberechnungsregel und Verantwortlichen.

Auch Z[Europe/London] ist im Sommer nicht automatisch widersprüchlich. Z behauptet keinen lokalen Null-Offset. Der Empfänger berechnet die Anzeige mit seinen Regeln; dieses Ergebnis gehört zu seiner laufenden Implementierung.

Künftige Ortszeit ist ein eigener Vertrag

RFC 9557 behandelt einen festen, auf UTC bezogenen Zeitpunkt. Schwebende Lokalzeit und eine künftige Ortszeit, deren zugehöriger Zeitpunkt sich nach einer Regeländerung verschiebt, sind ausdrücklich nicht gelöst.

Ein Sicherheitsablauf will vielleicht den Zeitpunkt festhalten, ein Arzttermin die örtliche 9-Uhr-Zusage. Das Datenmodell muss diese Invariante getrennt speichern. Die Syntax ist ein Interoperabilitätsbaustein, keine geschäftliche Zusage.

Kritisch heißt: nicht raten

Suffixe sind zunächst elektiv und dürfen ignoriert werden. Ein mit ! markiertes Suffix ist kritisch. Kann der Empfänger es nicht erkennen oder eine Inkonsistenz nicht sicher behandeln, darf er nicht so fortfahren, als fehle die Information. Fehler, Ablehnung oder ein anderer expliziter Nicht-Handlungsweg sind nötig.

Das Ausrufezeichen ist jedoch keine Ende-zu-Ende-Telemetrie. Queue, Schemawechsel, Signaturschicht oder Altdienst können den Zusatz verlieren. Wer behauptet, die Kritikalität habe die Entscheidung gesteuert, braucht Erhaltungsnachweise an jeder Grenze und einen Beleg am Entscheidungspunkt.

Bei wiederholten elektiven Schlüsseln gilt ohne Zusatzregeln der erste. Das macht die Auswertung deterministisch, erklärt aber nicht, ob ein Widerspruch durch Fehler, Wiederholung, Verunreinigung oder Angriff entstand.

Ein Registereintrag ist keine Installation

Das IANA-Register für Timestamp Suffix Tag Keys liefert gemeinsame Bezeichnungen. Der erste Schlüssel u-ca bindet einen Unicode-Kalenderbezeichner an. Er kann die kalenderbezogene Darstellung ändern, nicht den Zeitpunkt. Bibliotheksunterstützung, Erhaltung und Nutzung folgen daraus nicht.

Für Zugriffskontrolle zieht der RFC eine enge Grenze: Wo konsistente Interpretation erforderlich ist, eignen sich nur Erweiterungen mit gemeinsam verstandenem Verfahren zur Konfliktauflösung. Eine Annotation kann die Autorisierungsentscheidung nicht ersetzen.

Heng Lus Running-Code-Prinzip ordnet die Ebenen. Gemeinsam sein sollten nur strenge, lokal prüfbare Regeln: Syntax, registrierte Schlüssel, Kritikalität und Konfliktsignal. TZDB-Stand, Kalender, Ablehnung, Anzeige und Planungsabsicht bleiben bei den Systemen, die Code ausführen. Das Dokument koordiniert; Einsatz und beobachtetes Ergebnis schaffen betriebliche Wirklichkeit.