Résumé

  • Dans RFC 3339 d’origine, -00:00 signifiait que l’instant UTC était connu mais pas le décalage local, tandis que Z et +00:00 présentaient UTC comme référence privilégiée. RFC 9557 a ensuite attribué à Z le sens du décalage local inconnu, sans modifier +00:00.
  • Une égalité après normalisation ne constitue pas une égalité de preuve. La forme brute, la version du profil, la qualité de l’horloge, la table des secondes intercalaires, l’acte de capture et le résultat applicatif doivent rester des reçus distincts.

Une règle mise à jour relit l’archive

Le cas difficile n’est pas celui d’une date manifestement invalide. C’est celui d’une chaîne correctement analysée hier et relue aujourd’hui sous une règle plus récente. L’instant calculé peut être identique, alors que la provenance qu’on lui attribue ne l’est plus.

La section 4.3 de RFC 3339 réservait -00:00 à une situation précise : on connaissait l’heure UTC, mais pas le décalage vers l’heure locale. Z ou +00:00 indiquaient au contraire qu’UTC était le point de référence privilégié. Les formes pouvaient désigner la même seconde tout en transmettant des renseignements différents sur leur origine.

Ce choix venait du courrier électronique. RFC 2822, puis RFC 5322, donnent à -0000 le sens d’une date exprimée en temps universel sans information sur le fuseau local du système producteur. Le message répond à la question chronologique et garde ouverte la question locale.

RFC 9557 a corrigé une convention peu interopérable

Le signe négatif devant zéro posait un problème pratique. ISO 8601:2000 et ses versions ultérieures ne l’autorisaient pas, et les implémentations qui voulaient exprimer un décalage local inconnu utilisaient souvent Z. RFC 9557 a donc mis à jour RFC 3339 : Z peut désormais porter ce sens.

La mise à jour ne touche pas +00:00, qui continue de présenter UTC comme référence privilégiée. Elle ne déclare pas non plus -00:00 formellement obsolète, même si elle recommande Z à sa place.

Pour une enquête, il faut donc conserver deux dates : celle de l’événement et celle de la règle d’interprétation, ou plus exactement la version du profil applicable. Sans cette seconde information, une bibliothèque moderne peut donner à un ancien jeton un sens que son producteur n’avait pas.

La norme ne prouve toutefois pas qu’un logiciel précis a suivi l’ancienne ou la nouvelle règle. Cette conformité réclame des traces de version, de configuration et de test.

Le décalage numérique ne nommait pas un fuseau

RFC 3339 calcule le décalage comme heure locale moins UTC. Cette relation suffit à convertir l’instant représenté. Elle ne révèle ni un identifiant de zone, ni un pays, ni une règle de changement saisonnier, ni l’emplacement de la machine.

Plusieurs zones partagent le même décalage un jour donné et divergent ensuite. RFC 8536 décrit séparément le format TZif, avec ses transitions, types d’heure locale, désignations et corrections intercalaires. Ce sont des éléments absents d’un simple +02:00.

Conserver seulement l’instant UTC est utile pour aligner des événements. En déduire la configuration locale ou une intention civile future serait abusif. Il faut aussi la zone choisie, la version de sa base et la règle active à la date considérée.

Un décalage local inconnu n’était pas une heure flottante

Dans RFC 3339, l’incertitude ne porte pas sur l’instant. Celui-ci est connu en UTC ; c’est le lien avec l’heure locale qui manque. Le document refuse d’ailleurs l’heure locale non qualifiée pour les échanges Internet, parce qu’elle serait interprétée de travers presque partout ailleurs.

RFC 5545 offre un bon contre-exemple. Une heure iCalendar dite flottante n’est rattachée à aucune zone. Les mêmes champs d’horloge peuvent donc correspondre à des instants différents selon le lieu de l’utilisateur. C’est un comportement volontaire pour des rendez-vous du type « à 11 heures où que vous soyez ».

Réduire les deux cas à un champ timezone_unknown détruit leur différence. Le premier connaît l’instant et ignore son contexte local. Le second conserve une lecture murale et laisse précisément l’instant dépendre du contexte.

Le tri alphabétique avait un contrat étroit

RFC 3339 recherchait une propriété commode : dans certaines conditions, l’ordre des chaînes devient l’ordre du temps. Ces conditions sont explicites. Les zones doivent être identiques, écrites avec la même représentation, et le nombre de chiffres fractionnaires doit être le même.

Une collection qui mélange Z, des décalages différents et des fractions de longueurs variables n’entre pas dans cette garantie. La grammaire accepte aussi les lettres minuscules t et z, même si un protocole consommateur peut imposer les majuscules. Les errata vérifiés précisent certains passages rédactionnels et rappellent qu’il faut distinguer le profil Internet de la grammaire ISO collectée en annexe.

Avant un tri lexical, le système doit établir son profil de comparaison. Il peut dériver une forme canonique, mais il doit conserver la forme reçue afin de ne pas convertir une commodité d’indexation en perte de preuve.

Les décimales mesuraient l’écriture, pas la justesse

RFC 3339 ne garde qu’une option rarement utilisée : les fractions de seconde. Elles servent notamment aux besoins d’ordre strict ou de précision inhabituelle. Une suite plus longue décrit une granularité d’écriture ; elle ne certifie pas que l’horloge était aussi juste.

Un capteur mal synchronisé peut imprimer neuf décimales. Une source traçable peut n’en fournir aucune. RFC 5905 traite séparément la synchronisation NTP, sa hiérarchie, ses décalages et ses erreurs. Rien dans les caractères du timestamp ne remplace cet état de l’horloge.

Il faut donc distinguer nombre de décimales, résolution de l’appareil, dernière synchronisation, source de temps, incertitude et trajet de capture. Ajouter des zéros ne fabrique aucune observation nouvelle.

La seconde 60 demandait un calendrier extérieur

La syntaxe permet 60 à la fin d’un mois où une seconde positive est insérée. Elle envisage également une seconde négative, cas où le maximum pourrait être 58. Un parseur ne peut pas savoir par la seule grammaire si cette correction était prévue à la date donnée.

RFC 8536 montre que corrections et transitions résident dans des données versionnées ; RFC 5905 apporte un état de synchronisation distinct. Accepter 23:59:60 n’est donc qu’un reçu syntaxique tant que la date n’a pas été vérifiée contre la table compétente.

Les échelles posent en outre leurs propres frontières : certaines représentations comptent les secondes intercalaires, d’autres non. Comparer leurs nombres exige de conserver l’échelle et la transformation utilisées.

L’horodatage ne signait pas l’événement

RFC 3339 définit une manière d’écrire. Il n’authentifie ni l’émetteur, ni l’instant où la valeur a été ajoutée, ni les octets qu’elle couvre. Une date placée à côté d’une signature peut rester hors de la signature. L’heure de réception peut différer de l’heure de capture. Une date future bien formée peut venir d’une mauvaise configuration.

Le reçu durable relie la chaîne brute, le profil, l’instant dérivé, le jeton de décalage, l’état de l’horloge, l’incertitude, les données de zone et de saut, l’objet contenant, la couverture cryptographique, le transport et le résultat applicatif.

L’histoire de RFC 3339 donne une image nette de cette exigence : la chronologie peut rester stable quand la sémantique d’une représentation évolue. Garder l’une sans l’autre, c’est garder la bonne seconde et perdre la raison de lui faire confiance.

Sources