Zusammenfassung

  • Das ursprüngliche RFC 3339 verwendete -00:00 für einen bekannten UTC-Zeitpunkt mit unbekanntem lokalem Offset; Z und +00:00 erklärten UTC zum bevorzugten Bezug. RFC 9557 gab später Z die Unbekannt-Semantik und ließ +00:00 unverändert.
  • Gleiche normalisierte Zeitpunkte sind nicht gleiche Belege. Rohzeichen, Auslegungsprofil, Offset-Herkunft, Nachkommastellen, Uhrzustand, Schaltsekundendaten, Erfassung und Anwendungsergebnis benötigen getrennte Nachweise.

Eine Sekunde, zwei Aussagen

Ein Audit stößt auf zwei Eingaben, die dieselbe UTC-Sekunde ergeben. Eine Datenbank hat beide in eine kanonische Form gebracht. Für eine Zeitleiste reicht das; für die Frage, was der Erzeuger tatsächlich wusste, fehlt nun etwas.

Abschnitt 4.3 von RFC 3339 gab -00:00 ursprünglich eine enge Bedeutung: Die Zeit in UTC war bekannt, der Bezug zur Ortszeit unbekannt. Z und +00:00 implizierten dagegen, dass UTC der bevorzugte Referenzpunkt war. Die resultierende Sekunde konnte gleich sein, die Herkunftsaussage war es nicht.

Die Konvention kam aus Internet-Mail. RFC 2822 und später RFC 5322 verwenden -0000 für Universal Time ohne Information über die lokale Zeitzone des erzeugenden Systems. Der Zeitbezug bleibt erhalten; die lokale Herkunft wird ausdrücklich nicht behauptet.

Die Aktualisierung verschob die Semantik

RFC 9557 beschrieb das Interoperabilitätsproblem: ISO 8601:2000 und spätere Fassungen ließen -00:00 nicht zu. Implementierungen, die unbekannten lokalen Offset ausdrücken wollten, nutzten häufig Z. Die Aktualisierung passte RFC 3339 an diese Praxis an.

Danach kann Z den bekannten UTC-Zeitpunkt bei unbekanntem lokalem Offset ausdrücken. +00:00 blieb unverändert und bezeichnet UTC weiterhin als bevorzugten Bezug. -00:00 wurde nicht förmlich verworfen, doch Z wird an seiner Stelle empfohlen.

Damit wird die Profilversion zum Beleg. Wer nur den Zeitpunkt speichert, verliert den Token. Wer nur den Token speichert, kann ihn später mit einer anderen Regel lesen. Rohbytes, Bibliothek, Konfiguration und geltender Standard müssen verbunden bleiben.

Das Dokument belegt nicht, dass ein bestimmtes Produkt die Aktualisierung übernommen hat. Dafür braucht es Versions- und Testnachweise.

Ein Offset war keine Zeitzonenidentität

RFC 3339 definiert den numerischen Offset als Ortszeit minus UTC. Er erlaubt die Umrechnung des angegebenen Zeitpunkts. Er verrät weder einen Zonennamen noch Rechtsraum, Sommerzeitregeln oder Gerätestandort.

Mehrere Zonen können heute denselben Offset haben und morgen auseinanderlaufen. Das TZif-Format aus RFC 8536 führt Übergänge, lokale Zeittypen, Bezeichnungen und optionale Schaltsekundenkorrekturen getrennt. Genau diese Informationen fehlen im nackten Offset.

UTC-Normalisierung richtet Ereignisse aus, beweist aber keine installierte Zonendatenbank und keine zivilzeitliche Absicht. Konfigurations- und Versionsbelege bleiben nötig.

Unbekannter Offset war keine schwebende Ortszeit

Bei RFC 3339 ist nicht der Zeitpunkt unbekannt. Er ist in UTC bestimmt; nur sein Verhältnis zur Ortszeit fehlt. Unqualifizierte Ortszeit lehnte das Dokument für allgemeinen Internet-Austausch ab, weil sie fast überall außerhalb ihres Ursprungs falsch gedeutet würde.

RFC 5545 definiert dagegen bewusst „floating time“. Ein Termin um 11 Uhr kann für jeden Teilnehmer dieselbe Ziffernfolge tragen und je nach Aufenthaltsort zu einem anderen realen Zeitpunkt stattfinden.

Beides in ein Feld „Zeitzone unbekannt“ zu legen, vermischt zwei Ungewissheiten. Der erste Fall kennt den Zeitpunkt, aber nicht die lokale Herkunft. Der zweite kennt die Wanduhr und überlässt den Zeitpunkt dem Kontext.

Textsortierung hatte Vorbedingungen

RFC 3339 nannte die Möglichkeit, Zeitstempel als Zeichenketten zu sortieren. Dafür mussten Zeitzonen gleich sein, mit derselben Zeichenfolge erscheinen und dieselbe Anzahl von Nachkommastellen verwenden. Außerhalb dieses Korridors galt die Eigenschaft nicht.

Gemischte Offsets, Z neben +00:00 oder Bruchteile verschiedener Länge brechen die Voraussetzungen. Die Grundgrammatik erlaubt außerdem kleine t und z, auch wenn ein nutzendes Protokoll Großschreibung verlangen kann. Verifizierte Errata korrigieren redaktionelle und Anhang-A-Punkte; die dort gesammelte ISO-Grammatik ist nicht das schmale Internetprofil aus Abschnitt 5.6.

Eine kanonische Sortierspalte ist möglich, wenn Original und Transformationsregel erhalten bleiben. Sonst vernichtet ein Index die Herkunft.

Viele Stellen waren keine Genauigkeitsbescheinigung

Sekundenbruchteile waren die einzige selten genutzte Option des RFC. Sie dienten strenger Ordnung oder ungewöhnlicher Präzision und konnten eine oder mehrere Stellen tragen. Das beschrieb die Darstellung, nicht die Zuverlässigkeit der Uhr.

Eine unsynchronisierte Uhr kann neun Stellen ausgeben; eine rückführbare Quelle kann ganze Sekunden liefern. RFC 5905 behandelt NTP-Synchronisierung, Strata, Offsets und Fehler auf einer anderen Ebene. Der Zeitstring ist kein NTP-Zustandsbericht.

Darstellungspräzision, Auflösung, Quelle, letzte Synchronisierung, Unsicherheit und Erfassungspfad sind getrennt zu protokollieren. Nullen erhöhen keine Messqualität.

Die sechzigste Sekunde brauchte einen Plan

RFC 3339 erlaubt 60 am Monatsende einer positiven Schaltsekunde und berücksichtigt für eine mögliche negative Schaltsekunde den Höchstwert 58. Die Grammatik sagt nicht, ob für das Datum tatsächlich eine Korrektur angeordnet war.

RFC 8536 legt solche Korrekturen in versionierte Daten; RFC 5905 liefert anderen Uhrzustand. Ein akzeptiertes 23:59:60 ist ohne Abgleich mit dem zuständigen Plan nur syntaktisch gültig.

Zeitskalen zählen Schaltsekunden zudem unterschiedlich. Vor einem Vergleich müssen Skala, Tabelle und Konversion feststehen.

Der Zeitstempel war kein Ereignisnachweis

RFC 3339 standardisierte Schreibweise, nicht Urheber oder Wahrheit. Es belegt nicht, wann ein Feld angefügt wurde, welche Bytes eine Signatur deckt oder ob eine Handlung stattfand. Ein formal gültiger Zukunftswert kann aus Fehlkonfiguration stammen.

Ein belastbarer Beleg verknüpft Rohwert, Profil, abgeleiteten Zeitpunkt, Offset, Uhrquelle, Unsicherheit, Zonen- und Schaltdaten, Objekthash, kryptografische Deckung, Empfang und Anwendungsergebnis.

Die Geschichte des Formats zeigt die Grenze: Ein Zeitpunkt blieb derselbe, während ein späterer Standard die Auslegung eines Zeichens änderte. Chronologie und Herkunft gehören nebeneinander, nicht ineinander verdichtet.

Quellen