Zusammenfassung

  • RFC 9636 definiert die TZif-Darstellung, nicht die Quelle oder Aktualität der darin zusammengestellten zivilen Regeln.
  • Legacy-Block, 64-Bit-Tabelle, Trunkierung, Footer und Ablauf der Schaltsekundentabelle begrenzen die Aussage eines erfolgreichen Parses.
  • Der Beleg verbindet Absicht, Zonenauswahl, Quelle und Release, Dateihash, Gültigkeitsbereich, Leserentscheidung, Ergebnis und tatsächliche Ausführung.

Die Schaltsekundentabelle war abgelaufen. Der Reader rechnete trotzdem weiter und das Dashboard meldete lediglich „erfolgreich“.

RFC 9636 erlaubt genau diese operative Abzweigung: Nach einem Ablauf kann ein Leser ablehnen oder so fortfahren, als gäbe es das Ablaufdatum nicht, gegebenenfalls mit Fehlerhinweis. Beide Wege können regelkonform sein. Nur einer kann jedoch die Aussage „innerhalb bekannter Daten berechnet“ tragen.

Die Standards-Track-RFC ersetzt RFC 8536, bewahrt Austauschkompatibilität und führt Version 4 ein. Sie definiert nicht die Quelle der Regeln. Die IANA Time Zone Database ist eine mögliche Quelle; Dateikennung und Formatversion sind kein Nachweis ihres Releases.

Ablauf ist ein eigener Zustand

Version 4 darf Schaltsekundendaten am Anfang kürzen und mit dem letzten Eintrag ein Ablaufdatum markieren. Danach sagt die Tabelle nicht mehr, ob eine weitere Korrektur auftritt. Das unterscheidet fehlende Information von einer bestätigten Abwesenheit.

Die Resolution 4 der 27. CGPM behandelt die künftige Abschaffung von Schaltsekunden. Sie belegt nicht, welche Tabelle auf einem Host installiert war oder welche Codeverzweigung ausgeführt wurde. Institutioneller Beschluss, verteiltes Artefakt und Laufzeitverhalten brauchen getrennte Nachweise.

Auch der Medientyp ist begrenzt. application/tzif verlangt null Schaltsekundeneinträge; application/tzif-leap kann sie enthalten. Das Label beschreibt eine Klasse, nicht Aktualität oder Vollständigkeit eines konkreten Ergebnisses.

Der erste Block endet 2038

Jede Datei beginnt mit einem Version-1-Header und -Datenblock. Dessen 32-Bit-Zeiten reichen nur ungefähr von 1901 bis 2038. Version 2 und höher hängen einen 64-Bit-Block und einen Footer an.

Der alte Block kann ein Platzhalter sein. Ein veralteter Leser sieht dann keine Zeitwechsel; ein moderner überspringt ihn und nutzt die vollständigen Übergänge. Zwei erfolgreiche Parserläufe sind daher nicht zwingend zwei gleiche Interpretationen.

Zu protokollieren sind Formatversion, Reader und Bibliothek, gewählter Block, Datei- und Zählergrenzen, Hash, Quelle und Release. Insbesondere jenseits 2038 muss ein Test beweisen, dass kein Legacy-Pfad still übernommen hat.

Eine gültige Datei kann einen kleinen Zeitraum besitzen

Übergänge wählen lokale Zeittypen mit UT-Versatz, Sommerzeitflag und Bezeichnung. Der Typ gilt bis zum nächsten Übergang. Nach dem letzten Übergang liefert nur ein nicht leerer Footer eine Fortsetzungsregel; sonst ist lokale Zeit nicht bestimmt.

TZDIST darf Übergangsdaten kürzen. Eine solche Datei ist zwischen ihren ausgewiesenen Grenzen gültig. -00, ein Platzhaltertyp und ein leerer Footer machen Unwissen explizit. Ein Produkt, das außerhalb des Bereichs den letzten Versatz übernimmt, hat eine eigene Policy hinzugefügt.

Diese Policy kann vertretbar sein, darf aber nicht als Eigenschaft der Datei erscheinen. Sie braucht Besitzer, Version, Zeitfenster und Alarmierung.

Der Footer kann kein Gesetz vorwegnehmen

Der Footer kann eine POSIX-Regel für Zeiten nach dem letzten gespeicherten Übergang enthalten. Am Übergang muss sie konsistent sein. Das ist eine Nahtprüfung, keine Garantie künftiger staatlicher Praxis.

Bei einer neuen zivilen Regel erscheint ein neues Datenbank-Release. Für zukünftige Termine muss das Produkt entscheiden, ob es den Instant, die Wanduhrzeit oder eine erneute Bestätigung erhält. Wer Zone und Release nach früher UTC-Konvertierung löscht, kann diese Absicht später nicht wiederherstellen.

Abkürzungen lösen das Problem nicht. CST bezeichnet mehrere Regionen; gleiche Offsets können künftig auseinanderlaufen. Zonenauswahl und Auswahlweg sind eigene Beweisdaten.

Integrität gehört zur Lieferkette

TZif besitzt keinen eingebauten Integritäts- oder Vertraulichkeitsschutz. Seine gezählten Arrays verlangen Längen- und Indexprüfung. Öffentliche Verteilung muss extern, etwa durch TLS, geschützt werden, weil manipulierte Regeln Kalender und Scheduler schädigen können.

TLS schützt den Transport zu einem Endpunkt. Es beweist nicht das richtige Quellrelease, die Frische des ETag, einen Cache-Refresh oder die spätere Unverändertheit der lokalen Datei. Der Lieferbeleg umfasst Quelle, Release, URL, ETag, Abrufzeit, Hash, Cachealter und Installation.

Eine Zonenabfrage kann zudem vergangenen, aktuellen oder künftigen Aufenthaltsort verraten. Öffentliche Regelwerke machen Auswahlprotokolle nicht öffentlich.

Von der Wanduhr zur Wirkung

RFC 3339 trägt Instant und Offset, RFC 9557 kann eine benannte Zone ergänzen, RFC 5545 beschreibt Kalenderobjekte. Keines liefert automatisch den exakten TZif-Hash und die Policy für doppelte oder ausgelassene Wanduhrzeiten.

Die Übergangstabelle zeigt Kandidaten. Die Anwendung entscheidet früher, später, verschieben, ablehnen oder nachfragen. Danach folgt der Wirkungsbeleg: Start des Jobs, Öffnung des Fensters, Versand der Nachricht.

Die Kette trennt zivile Absicht, Zone, Quelle, Artefakt, Reader, Rechenergebnis, Anwendungsentscheidung und Wirkung. RFC 9636 vereinheitlicht Bytebedeutung; es erteilt keine Vollmacht über Ort, Gesetz oder Ergebnis.

Quellen