Résumé

  • La RFC 868 a défini une valeur de 32 bits comptant les secondes depuis le 1er janvier 1900, renvoyée sur TCP ou UDP au port 37.
  • La limite de 2036 figurait dès le standard. L’instant exact se calcule à partir du champ, mais le texte ne donne que l’année.
  • NTP a ensuite pris en charge la synchronisation des horloges et l’interprétation des ères, au-delà d’un simple échantillon horaire.

Une réponse commune, pas une horloge commune

Certains systèmes n’avaient pas d’horloge de calendrier et toute horloge pouvait comporter une erreur humaine ou mécanique. La RFC 868 proposait de sonder brièvement plusieurs sites indépendants pour vérifier ou corriger l’heure locale. Elle fournissait une représentation lisible par machine ; elle ne prétendait pas synchroniser seule tous les systèmes.

Le nombre correspondait aux secondes depuis minuit GMT le 1er janvier 1900. Le serveur écoutait au port 37. En TCP, le client se connectait, recevait une valeur binaire de 32 bits, puis la connexion se fermait. En UDP, il envoyait un datagramme vide et en recevait un contenant la valeur. Si le serveur ne connaissait pas son heure, il devait s’abstenir : refus ou fermeture sans valeur en TCP, absence de réponse en UDP.

Le protocole n’explique pas comment compenser le délai réseau, choisir un serveur fiable, authentifier sa réponse ou régler l’oscillateur local. Une valeur que la machine peut décoder n’est donc pas automatiquement une mesure exacte.

L’autre service de l’heure

La RFC 867 Daytime, parue le même mois, envoyait une date en ASCII sur le port 13, notamment pour le débogage et la mesure. Elle recommandait des caractères imprimables sans imposer une syntaxe unique. Sa note renvoyait les usages machine à la RFC 868. Les textes distinguent la représentation et l’usage, pas la précision de deux horloges concrètes.

Le point de départ de 1900 précède l’époque Unix de 1970. La RFC 868 donne la conversion : minuit GMT le 1er janvier 1970 vaut 2 208 988 800 dans son compteur. Un origine fixe rend les nombres comparables si les deux systèmes partagent unités et convention.

Le compromis avait une date limite explicite : « jusqu’en 2036 ». Un compteur non signé de 32 bits atteint 2³² secondes le 7 février 2036 à 06:28:16 GMT. Cette heure précise est un calcul depuis l’origine et la largeur du champ ; la RFC ne dit que l’année. La seconde suivante ne tient plus dans la plage et le compteur repart à zéro. Sans contexte, une valeur après le bouclage peut correspondre à une autre période qu’une valeur identique avant celui-ci.

De l’échantillon à la synchronisation

En 1985, la RFC 958 décrivait NTP comme issu de la RFC 868 et du message ICMP Timestamp, et comme remplaçant approprié des deux. NTP visait la synchronisation d’un ensemble d’horloges au moyen de clients et de serveurs distribués ; son rôle dépassait le retour d’une seule lecture.

NTP conservait l’époque de référence de 1900, mais devait traiter plusieurs ères. La RFC 5905 décrit les secondes sur 32 bits et le passage de l’ère 0 à l’ère 1 en 2036. L’horodatage transmis contient aussi une fraction ; retrouver l’ère complète nécessite encore du contexte. La connaissance approximative de la date permet de lire les valeurs autour du bouclage.

La RFC 868 n’est donc pas devenue éternelle par magie. Elle a allégé une requête et déclaré la durée prévue de sa base. NTP a ensuite intégré la synchronisation et l’interprétation des ères comme des problèmes plus larges. Dès 1983, le standard montrait que 1900 avait été mis sur le fil, mais qu’un compteur isolé ne pourrait pas indiquer indéfiniment à quelle période il appartient.

Sources et limites

La source principale est la RFC 868, Time Protocol, de mai 1983. Les RFC 867, 958 et 5905 éclairent respectivement le service ASCII contemporain, la filiation revendiquée par NTP et le traitement ultérieur des ères. Elles ne prouvent ni le nombre de serveurs déployés, ni leur précision, ni une migration universelle, ni une panne en 2036.

La RFC 2626 signale également le bouclage de 2036 ; l’heure précise qu’elle imprime diffère du calcul ci-dessus. Cet article ne reprend donc que son avertissement sur l’année (RFC 2626). La Note 65 de Heng Lu a nourri la question éditoriale sur la façon dont les implémentations prolongent une règle écrite ; elle sert de grille de lecture, pas de preuve historique (Note 65).