Résumé

  • RFC 867 précisait le port, le transport et la fin de l’échange Daytime, mais déclarait qu’aucune syntaxe particulière ne régissait la date renvoyée.
  • Les deux présentations proposées n’étaient que des usages populaires. Pour une valeur destinée au calcul, le texte renvoyait explicitement vers le protocole Time de RFC 868.
  • Les normes ultérieures sur les horodatages ont séparé une représentation réseau stable de l’affichage local. Daytime montre ce qui arrive quand cette séparation reste du côté de l’humain.

La réussite qui ne suffit pas au logiciel

Une machine affiche Monday, February 22, 1982 17:37:43-PST. Une autre préfère 02 FEB 82 07:59:01 PST. Le lecteur comprend l’intention. Le programme, lui, doit inventer des règles : année à deux ou quatre chiffres, tiret ou espace avant le fuseau, valeur du jour de la semaine, langue des mois, présence des secondes.

RFC 867 n’imposait aucun de ces deux modèles. Après avoir affirmé qu’il n’existait pas de syntaxe Daytime spécifique, le document les présentait seulement comme deux formes populaires. Un parseur capable de lire la seconde ligne connaît donc une convention locale ; il ne connaît pas « le format RFC 867 », puisque ce format n’existe pas.

La distinction est plus profonde qu’une bizarrerie ancienne. Un protocole peut être interopérable pour la connexion et les octets, mais ne pas l’être pour la transformation sémantique que voudrait effectuer le client. Le serveur a tenu sa promesse en livrant une ligne lisible. Le client n’a reçu aucune promesse sur la manière de la convertir en instant.

Un service volontairement minuscule

Publié en mai 1983, RFC 867 qualifiait Daytime d’outil utile de débogage et de mesure. En TCP, le serveur écoutait sur le port 13, envoyait la date et l’heure courantes sous forme de chaîne ASCII dès la connexion établie, ignorait les données reçues puis fermait. En UDP, tout datagramme arrivé au même port déclenchait un datagramme de réponse ; son contenu n’était pas interprété.

La norme recommandait des caractères ASCII imprimables, l’espace, le retour chariot et le saut de ligne. La réponse devait tenir sur une seule ligne. Ces contraintes facilitaient l’inspection avec des outils simples et limitaient le cadre de l’échange.

Elles ne fixaient ni l’ordre des champs, ni les séparateurs, ni la précision, ni le nombre de chiffres de l’année, ni le rapport à UTC, ni la notation d’une seconde intercalaire, ni la langue, ni la qualité de l’horloge. Le mot « courant » décrivait ce que le serveur affirmait envoyer ; il ne certifiait ni synchronisation ni exactitude.

Le port enregistré ne comblait pas ces absences. Il identifiait le service attendu, pas l’autorité de l’opérateur sur le temps civil. Recevoir de l’ASCII du port 13 ne prouvait ni l’identité de la source, ni la justesse de son horloge, ni l’univocité de PST.

Pour la machine, une autre porte

La dernière note de RFC 867 tranche sans détour : pour une heure utile à la machine, il faut employer RFC 868. Le protocole Time livrait sur le port 37 un entier non signé de 32 bits comptant les secondes depuis le début de 1900. Daytime offrait des mots sur le port 13 ; Time offrait une quantité fixe sur le port 37.

Il serait donc faux de décrire Daytime comme une tentative ratée de synchronisation ou de sérialisation. Sa fonction humaine était assumée. Un technicien pouvait vérifier qu’un hôte répondait et observer son horloge sans posséder de décodeur. Le programme qui devait comparer ou calculer disposait d’un service voisin conçu pour cela.

Le catalogue RFC 880 d’octobre 1983 classait d’ailleurs Daytime comme « elective » : un hôte pouvait l’implémenter ou non. Time était « recommended », donc encouragé pour tous les hôtes. Ce classement historique ne mesure pas l’usage actuel, mais il confirme la hiérarchie fonctionnelle de l’époque.

Les deux choix avaient leurs limites. La phrase Daytime était parlante mais non normalisée. Le nombre Time était commun mais dépourvu d’affichage, de fuseau et, à plus long terme, de contexte d’ère. Le sujet ici n’est pas le basculement de 2036 déjà traité ailleurs ; c’est le partage initial de responsabilité entre l’œil et le calcul.

Le lundi devenu mardi

Le premier exemple de RFC 867 associait à l’origine le 22 février 1982 au mardi. C’était un lundi. L’erratum 8551, vérifié par le RFC Editor en 2025, a corrigé le jour. Il s’agit d’une correction éditoriale, pas d’une modification du protocole ni d’une preuve sur les serveurs déployés.

Cet écart révèle néanmoins une propriété précise. Écrire à la fois le jour de la semaine et la date fournit deux énoncés sur le même fait. Ils peuvent diverger. L’humain hésite ; un programme doit choisir quel champ domine. Daytime ne donnait aucune règle d’arbitrage, puisqu’il ne donnait aucune grammaire.

RFC 3339 a formulé plus tard cette catégorie de risque pour les horodatages Internet. Le document écartait le jour de la semaine, précisément parce qu’une information redondante peut contredire la date. Il imposait quatre chiffres pour l’année, une relation déclarée avec UTC et un décalage numérique ou Z, au lieu d’abréviations alphabétiques notoirement ambiguës.

Il ne faut pas inventer une filiation : RFC 3339 n’a pas remplacé RFC 867, et l’erratum tardif ne l’a pas provoqué. La comparaison montre deux contrats différents. L’un laisse le rendu au serveur pour être regardé. L’autre resserre la forme réseau afin que des programmes indépendants puissent identifier le même instant.

Lire localement, échanger mondialement

RFC 3339 ne condamnait pas les protocoles lisibles. Il soulignait au contraire leur valeur pour le débogage. Mais il rappelait qu’aucun format de date n’est naturel dans tous les pays. Sa réponse consistait à stabiliser la représentation échangée, puis à laisser le client la traduire pour son lecteur.

Daytime plaçait ce choix d’affichage chez le serveur. C’est pratique tant qu’un humain regarde. Dès qu’un script capture la ligne, le vocabulaire, le fuseau et la ponctuation du serveur deviennent une API implicite. Une expression régulière écrite après observation d’un hôte peut sembler fiable pendant des années. Le jour où l’administrateur change la présentation, le serveur reste conforme et le script casse.

Ce n’est pas une violation de la norme. C’est la découverte tardive qu’une sortie destinée aux yeux a été promue en contrat de données sans accord. L’automatisation défendable conserve la chaîne comme preuve opaque ou obtient une convention explicite distincte.

L’enregistrement IANA n’ordonne pas l’ouverture

IANA associe toujours daytime aux ports TCP et UDP 13 avec RFC 867 comme référence. Cet enregistrement garantit un sens dans un espace de noms. Il ne garantit ni déploiement, ni sécurité, ni légitimité du trafic, et n’oblige aucun opérateur à exposer le service.

La variante UDP exige une décision contemporaine. Elle répond sans interpréter la demande, tandis qu’une adresse source IP peut être usurpée. RFC 8085 avertit que les services répondant largement à de petites requêtes non authentifiées peuvent alimenter une amplification et recommande de limiter ou d’authentifier la réponse selon le contexte. Les sources disponibles ne mesurent ni fréquence d’abus Daytime ni facteur universel.

La bonne question n’est donc pas « le port est-il standard ? », mais « pourquoi cette réponse est-elle joignable et quelle autorité lui accordons-nous ? ». Une connexion TCP n’authentifie pas l’horloge. Un datagramme UDP ne certifie pas le demandeur. Une phrase lisible ne transforme pas un hôte en référence temporelle.

La frontière utile de RFC 867

La force de cette petite norme tient à sa retenue. Elle rendait prévisible l’ouverture, la réponse et la fermeture. Elle laissait le résultat facile à lire. Puis elle refusait de promettre une syntaxe qu’elle ne voulait pas gouverner.

Un développeur peut bien sûr analyser une réponse particulière. La question institutionnelle est différente : la norme autorise-t-elle à croire que cette analyse survivra à tous les serveurs conformes et à tous leurs changements ? Pour Daytime, la réponse est non.

L’interopérabilité possède ainsi plusieurs couches. Le port peut être commun quand la date ne l’est pas. Les caractères peuvent être valides quand l’instant reste ambigu. Le serveur peut respecter RFC 867 quand l’automatisation échoue. Le contrat devient fiable seulement lorsque chacun sait quelle inférence la norme garantit — et laquelle elle laisse volontairement à l’extérieur.

Sources et limites

Le mécanisme Daytime provient de RFC 867, avec la correction d’exemple dans le registre des errata. La comparaison machine vient de RFC 868, et le statut historique de RFC 880.

La discipline ultérieure des horodatages est documentée par RFC 3339. RFC 6335 et le registre IANA bornent la signification du port ; RFC 8085 fournit les précautions UDP modernes. Aucune de ces sources ne donne un taux actuel d’usage, d’exactitude ou d’abus.