Résumé

  • RFC 9557 ajoute à l’horodatage RFC 3339 un suffixe facultatif pour le fuseau, le calendrier ou une future extension ; le suffixe enrichit le contexte sans embarquer les règles effectivement exécutées.
  • Dans cette mise à jour, Z signifie que l’instant UTC est connu mais que le décalage local ne l’est pas. +00:00 affirme, lui, un décalage nul.
  • Le marqueur critique impose de ne pas continuer si le suffixe ne peut être traité. Il ne certifie pas que les intermédiaires l’ont conservé ni que l’application finale a obéi.

Une date accompagnée de [Europe/Paris] paraît plus complète qu’un simple nombre de secondes. Elle ne constitue pourtant pas une capsule contenant la législation horaire, la version de la base de données et la décision du produit. RFC 9557, publié sur la voie Standards Track en avril 2024, définit IXDTF précisément pour mieux transporter ce contexte autour d’un instant référencé à UTC. Sa force vient de la limite qu’il ne cherche pas à abolir.

La lettre Z conserve une incertitude

La modification la plus facile à manquer concerne Z. RFC 9557 lui attribue le sens de -00:00 : l’instant UTC est connu, le décalage local reste inconnu. +00:00 affirme au contraire un décalage zéro et peut signaler qu’UTC est la référence préférée. Le calcul de l’instant peut être identique alors que la provenance ne l’est pas.

Une normalisation trop zélée détruit cette différence. Si une base ne garde que l’époque Unix, ou si un sérialiseur réécrit toutes les formes en Z, l’auditeur ne saura plus ce que le producteur avait réellement déclaré. Il faut conserver les octets d’origine, le résultat normalisé et la version du parseur. L’horodatage « valide » ne suffit pas à décrire la perte d’information.

Un nom de fuseau n’identifie pas une édition de TZDB

Le suffixe de fuseau désigne un ensemble de règles, pas une livraison précise de l’IANA Time Zone Database. Or les décisions politiques changent, les versions de TZDB se succèdent et les déploiements ne progressent pas ensemble. Producteur et destinataire peuvent donc être corrects selon leurs propres données tout en calculant des décalages différents.

IXDTF permet de voir une incohérence entre le décalage numérique et le fuseau. Il ne décide généralement pas lequel doit l’emporter. Une réunion lointaine illustre le problème : l’organisateur voulait-il préserver l’instant absolu ou neuf heures sur l’horloge locale ? Une nouvelle règle nationale peut rendre ces deux objectifs incompatibles. La chaîne doit garder l’invariant choisi, la version TZDB, la politique de recalcul et le responsable de la décision.

Z[Europe/London] n’est pas incohérent par principe, même lorsque Londres applique l’heure d’été. Z ne prétend pas que le décalage local vaut zéro ; le destinataire calcule l’affichage à partir de ses propres règles. Ce calcul appartient à son système en fonctionnement.

L’instant fixe n’est pas un rendez-vous futur

Le périmètre de RFC 9557 est l’instant référencé à UTC. Le document exclut explicitement le temps local flottant et le problème du rendez-vous futur dont l’instant peut changer avec les règles de fuseau. Une échéance financière peut exiger de conserver l’instant ; une consultation médicale peut exiger de conserver l’heure murale. La syntaxe ne peut pas choisir l’obligation métier.

Cette séparation est utile au pilotage. Elle empêche de présenter une décision de produit comme une conséquence du standard. Le standard rend l’échange déterministe ; l’organisation doit rendre son engagement explicite.

Critique veut dire : ne pas improviser

Un suffixe est électif par défaut. Le destinataire peut l’ignorer. Avec !, il devient critique : si le destinataire ne le reconnaît pas ou détecte une incohérence qu’il ne sait pas traiter, il ne doit pas agir comme si l’information n’existait pas. Il faut une erreur, un rejet ou une autre voie de non-action explicite.

Mais le point d’exclamation n’est pas une télémétrie. Une file peut supprimer le suffixe, un schéma peut l’aplatir, une signature peut canoniser une autre forme, un service peut ne lire que le préfixe RFC 3339. La preuve d’application exige un test de conservation de bout en bout et un reçu au point où la décision est prise.

Les clés dupliquées confirment ce partage des responsabilités. Sans règle supplémentaire, la première occurrence élective prévaut. La règle évite une fusion inventée ; elle n’explique pas si la contradiction vient d’une panne, d’une nouvelle tentative ou d’une entrée hostile.

L’enregistrement IANA n’est pas le déploiement

Le registre IANA des clés de suffixe fournit des noms stables. La clé initiale u-ca relie l’horodatage à un identifiant de calendrier Unicode. Elle peut modifier la présentation calendaire ; elle ne déplace pas l’instant. Elle ne prouve pas non plus le support de la bibliothèque, la compréhension de l’utilisateur ou l’adoption dans un processus.

La doctrine de Heng Lu fixe la bonne lecture. La couche commune doit rester minimale et vérifiable : grammaire, clés enregistrées, règles critiques et signalement des incohérences. Les choix futurs — version TZDB, calendrier, rejet, affichage, invariant de planification — restent locaux aux participants qui exécutent le code. Le document coordonne ; l’adoption, la décision et le résultat observé rendent la règle réelle.