Résumé

  • RFC 9636 définit le sens des octets d’un fichier TZif, mais pas l’origine des règles civiles qui l’ont produit ni leur actualité.
  • Bloc de compatibilité 32 bits, table 64 bits, troncature, footer et expiration des secondes intercalaires délimitent chacun ce que le résultat peut affirmer.
  • Une preuve exploitable relie intention, zone, édition de la base, empreinte du fichier, plage couverte, comportement du lecteur, heure rendue et action finale.

Le fichier contenait les transitions connues. Entre sa génération et le rendez-vous, la règle civile avait changé.

Le calcul restait reproductible, mais il ne répondait plus à la question présente. C’est la distinction que RFC 9636 permet de garder nette : une norme de représentation peut être exacte sans devenir l’autorité sur la source, le territoire ou l’avenir.

Le document remplace RFC 8536, conserve la compatibilité d’échange et introduit la version 4. Il ne définit pas la provenance des données assemblées. La base IANA des fuseaux horaires, administrée selon une procédure distincte, en est une source possible. Un fichier sans identifiant d’édition demeure donc un témoin sans date de déposition.

Deux lectures légitimes des mêmes octets

Tout objet commence par un en-tête et un bloc version 1. Leurs temps de transition sur 32 bits ne couvrent qu’environ 1901 à 2038. Les versions 2 et suivantes ajoutent un bloc sur 64 bits et un footer, tout en gardant la première partie pour les lecteurs anciens.

Un producteur peut écrire un bloc version 1 réduit à un espace réservé. Le lecteur obsolète conclut alors qu’il n’existe ni changement d’heure ni abréviation ; le lecteur moderne saute ce bloc et consulte les transitions riches. Les deux ont « ouvert » le fichier. Ils n’ont pas lu le même contrat temporel.

Le reçu doit donc conserver la version du format, la capacité du lecteur, le bloc choisi, les contrôles de longueur et d’indices, l’empreinte de l’objet et l’édition de la source. Sans cela, un simple numéro de décalage masque la chaîne de calcul.

L’inconnu est une donnée, pas une panne d’interface

Une transition sélectionne un type d’heure locale : décalage à UT, indicateur d’heure d’été et désignation. Le type vaut jusqu’à la transition suivante. Avant la première, le type zéro s’applique. Après la dernière, le footer s’applique s’il est présent et non vide ; sinon, l’heure locale est inconnue.

Le service TZDIST peut livrer un objet tronqué. La validité se limite alors à l’intervalle annoncé par ses transitions de début et de fin. Le marqueur -00 et un footer vide permettent d’écrire explicitement « non spécifié ». Remplacer ce résultat par la zone du serveur, le dernier décalage ou UTC ne répare pas le fichier : cela ajoute une politique qui doit être nommée.

Cette modestie compte pour les archives comme pour le futur. Une donnée compacte peut suffire à une application limitée, à condition que l’application vérifie que l’instant demandé appartient bien à son domaine.

Le footer prolonge une règle, pas un parlement

Le footer contient éventuellement une règle POSIX pour calculer les changements après la dernière transition stockée. Il doit être cohérent avec celle-ci au point de raccord. Cette continuité interne ne prouve pas que la règle civile restera inchangée.

Lorsqu’une autorité modifie sa pratique, la source publie une nouvelle édition. Pour un événement futur, il faut alors décider ce qui prime : l’instant déjà fixé, l’heure murale voulue ou une nouvelle confirmation. Une conversion UTC enregistrée seule a détruit cette question.

Les abréviations n’aident pas à retrouver l’intention. CST peut désigner des contextes chinois, cubain ou nord-américain. Un décalage numérique peut être partagé aujourd’hui par des zones qui divergeront demain. Le sélecteur de zone et la manière dont il a été choisi font partie de la preuve.

La version 4 donne une borne au savoir sur les secondes

La version 4 autorise une table de secondes intercalaires tronquée au début et un dernier enregistrement marquant son expiration. Après cette échéance, la table ne dit plus si une correction future aura lieu.

Le lecteur peut refuser de continuer ou calculer comme si l’expiration n’existait pas, éventuellement avec un signal d’erreur. Ces comportements peuvent tous deux respecter la norme ; ils ne soutiennent pas la même décision. Un statut vert doit donc exposer le choix, l’échéance et l’avertissement.

La résolution de la 27e CGPM sur l’arrêt futur des secondes intercalaires appartient à un autre niveau d’autorité. Elle ne prouve ni la table chargée par un système ni la branche prise par son code.

La sécurité du transport ne date pas la règle

TZif n’embarque aucune protection d’intégrité ou de confidentialité. Ses tableaux comptés exigent des contrôles de bornes ; sa distribution publique doit être protégée, par exemple avec TLS. Une session TLS authentifie un transport, pas l’actualité sémantique du fichier.

La chaîne utile comprend source, édition, URL, ETag, date de récupération, empreinte, âge du cache et résultat d’installation. Elle doit ensuite rejoindre l’application : instant demandé, résultat local, ambiguïté lors d’un recul d’horloge, choix plus tôt ou plus tard, et effet constaté.

RFC 3339 encode un instant et son décalage ; RFC 9557 peut ajouter une zone nommée ; RFC 5545 porte des objets calendaires. Aucun ne transforme à lui seul un fichier de règles en preuve que la réunion a commencé selon l’intention humaine.

Les sept pièces du reçu

Conservez l’intention civile, la zone sélectionnée, l’édition source, l’objet exact, son intervalle, le lecteur et sa politique, puis l’effet de l’application. Séparez l’heure affichée de la décision prise lors d’une heure inexistante ou répétée. Séparez enfin la décision du résultat réellement observé.

La norme a autorité sur la syntaxe et l’interprétation des octets. Elle ne choisit ni la ville, ni la version installée, ni la réaction à l’ambiguïté, ni l’heure à laquelle une opération s’est effectivement déclenchée.

Sources