Toute machine informatique dispose d'une horloge interne pour cadencer son processeur. Le le plus souvent, cette horloge est basée sur un oscillateur électronique à quartz externe W (cf. celui d'une carte Arduino en photo ci‑contre). Ce dispositif génère un signal périodique d'horloge W de (très) haute fréquence – au moins 1 MHz, mais le plus souvent de l'ordre du GHz. Il définit ce qu'on appelle le temps processeur (cf. chap. C2‑IX ).

En comptant le nombre d'impulsions du signal d'horloge depuis un instant initial, on peut en déduire la durée écoulée, et donc, moyennant quelques calculs, implémenter un temps calendaire, c'est‑à‑dire une horloge qui indique la date et heure courante conformément à la localisation du système, c'est‑à‑dire sa position dans le système des zones horaires du monde (cf. la capture d'écran ci‑contre sur un PC Windows).

Néanmoins, tout oscillateur électronique comporte des imperfections qui lui sont propres. Au fil du temps, même un écart minime sur la fréquence d'oscillation par rapport à la valeur théorique finit par engendrer une dérive significative du système d'horodatage de la machine, avec des conséquences non négligeables.

Dans le cas d'un poste de travail, tout l'étiquetage des fichiers et des processus (cf. la capture d'écran ci‑contre) risque d'être faussé par rapport à la réalité.
• Dans un réseau informatique, certains services – notamment la messagerie électronique, les requêtes sur bases de données – requièrent une bonne synchronisation entre les machines, qui peut être compromise par un écart entre les horloges respectives des serveurs.

Dans un système de production qui met en œuvre un processus d'horodatage des produits, si ce dernier n'est pas exact, cela risque de poser des problèmes ultérieurs de traçabilité.

On comprend donc la nécessité de synchroniser régulièrement les horloges des machines avec une référence de temps commune.

Mais définir une référence de temps commune n'est pas simple. Cette problématique ancienne, qu'on a cru pouvoir résoudre avec les observations astronomiques, s'est complexifiée avec l'amélioration des techniques de mesure du temps. Aujourd'hui, on distingue principalement deux échelles de temps.

D'une part, on a le temps universel W (universal time, abrégé UT) qui est basé sur les notions de jour solaire moyen et d'année tropique. L'inconvénient de cette unité est qu'elle a une durée variable (certes, très faiblement, mais néanmoins gênante lorsqu'il s'agit de chronométrer des phénomènes). En revanche, elle offre à l'échelle d'une année une synchronisation avec l'alternance des jours et des saisons que l'on constate sur Terre, donc en phase avec les activités humaines.

D'autre part, on a le temps atomique international W (international atomic time, abrégé TAI) qui est exclusivement basée sur la définition atomique de la seconde comme unité fondamentale du temps propre terrestre (car sa valeur est très proche d'une fraction remarquable du jour solaire moyen). Aux incertitudes techniques près, la durée d'une seconde atomique est extrêmement stable.

Si le temps atomique international est privilégié pour les expériences scientifiques, il n'est en revanche pas retenu comme référence pour le temps civil – et donc dans les systèmes informatiques – car il présente une dérive par rapport au temps universel, certes très faible (de l'ordre d'une minute par siècle) mais techniquement insatisfaisante : il est difficile d'accepter que les saisons se décalent peu à peu dans le calendrier.

Depuis la fin des années 1960, c'est un concept intermédiaire appelé temps universel coordonné W (en anglais, coordinated universal time), abrégé officiellement UTC, qui est adopté, pour offrir un bon compromis entre les deux échelles de temps présentées supra.

L'adoption de l'UTC comme référence de temps mondiale n'a de sens que si elle peut être facilement partagée entre les machines. Sur l'Internet ont donc été développés des protocoles de communication spécifiques : d'abord TP W (time protocol) puis NTP W – pour network time protocol – dont la version 4 (juin 2010) est la plus récente aujourd'hui. C'est sur ce protocole que reposent la plupart des services de temps sur les réseaux.

Comme presque tous les protocoles applicatifs, NTP est conçu sur un modèle client‑serveur et une architecture spécifique. Pour un technicien réseau, il est nécessaire d'en connaître les bases, auquel le présent chapitre est justement consacré, avec les objectifs listés ci‑dessous

• Tout d'abord, on décrit la problématique générale de la définition du temps, en rappelant :
• d'une part, la définition de la seconde atomique qui constitue l'étalon de durée ;
• d'autre part, les notions de jour solaire et d'année tropique.
On peut alors introduire :
• la notion de temps universel et ses concepts sous‑jacents de fuseau horaires et d'heure d'été.
• la notion de temps universel coordonné avec la notion sous‑jacente de seconde intercalaire ;
• Dans un deuxième temps, on aborde les représentations du temps calendaire dans les systèmes informatiques, en introduisant la notion de timestamp.
• Ensuite, on décrit le système de partage du temps universel coordonné, en détaillant l'architecture réseau pour les serveurs de temps et le protocole NTP.
• Enfin, on aborde les différentes techniques de manipulation des paramètres calendaires dans une machine informatique.

Pour une étude plus approfondie, on pourra consulter les pages web  rédigées à titre pédagogique par l'Université du Delaware. Ce n'est pas un hasard car cette université compte parmi ses effectifs David L. Mills W, professeur émérite et principal concepteur du protocole NTP.

Problématique générale de la définition du temps

La définition d'une échelle de temps constitue une problématique très ancienne pour les sociétés humaines (cf. la photo d'un vestige de cadran solaire égyptien, vieux d'environ 3300 ans). La problématique a beaucoup évoluée au gré des besoins en précision requis par les activités sociales et des progrès accomplis, à la fois dans les techniques de mesure des durées et la compréhension des phénomènes astronomiques.

Aujourd'hui, l'unité de temps – la seconde – est celle qui est la mieux maîtrisée de toutes les unités du système international. Et les phénomènes astronomiques qui gouvernent le temps terrestre sont bien compris.

Néanmoins, cinquante ans après son adoption, l'échelle du temps universel coordonné fait encore l'objet de controverses – certains scientifiques préférant qu'on privilégie le temps atomique international.

La seconde atomique : un étalon de durée

En 1967, par la résolution nº 1 de la 13^e Conférence générale des poids et mesures , la seconde a été définie comme la durée de 9 192 631 770 périodes de la radiation correspondant à la transition entre les deux niveaux hyperfins de l'état fondamental de l'atome de césium 133.

Les horloges atomiques  –  le temps atomique

Une horloge atomique W est une machine qui délivre un signal périodique de fréquence connue et très stable basée sur des phénomènes atomiques.

Dans le cas de technologie dite à jet de césium (cf. l'équipement en photo ci‑contre à titre d'exemple), cette fréquence est de 9 192 631 770 Hz – en rappelant que 1 Hz = 1 s⁻¹. Des dispositifs électroniques appelés diviseurs de fréquences permettent notamment d'en extraire un signal périodique de période 1 seconde très précisément.

Les horloges atomiques sont notamment utilisées pour :

• définir la seconde atomique et ainsi compter l'écoulement du temps atomique international ;
• par la même occasion, fournir la base du temps universel coordonné ;
• implémenter un service de temps embarqué dans les satellites des systèmes de localisation (GPS, Glonass, Galileo…) et plus généralement dans tous les systèmes qui requièrent une échelle de temps extrêmement précise, ne devant pas être entachée par des délais de transmission.

Le jour solaire : un phénomène de durée variable

On peut définir intuitivement le jour solaire W comme la durée supposée périodique entre deux passages consécutifs du Soleil dans le plan méridien W d'un même lieu terrestre, principalement (mais pas seulement…) du fait de la rotation de la terre sur elle‑même.

Avec des moyens de mesure rudimentaires (une horloge du commerce), on peut constater sans difficulté que cette durée n'a pas de valeur constante tout au long de l'année.

Pour bien comprendre les multiples facteurs qui impactent la durée du jour solaire, rappelons déjà qu'il faut ne pas confondre cette notion avec celle de jour sidéral W qui est la durée de rotation de la Terre sur elle‑même lorsqu'elle est considérée dans un repère stellaire – d'où le terme « sidéral » W. Cette durée peut être précisément mesurée par chronométrage de deux passages successifs d'une étoile lointaine dans un système de visée fixe sur Terre ; elle vaut environ 23 heures 56 minutes.

Pour terminer un jour solaire complet, il faut qu'un point pris comme référence à la surface terrestre se retrouve exactement face au Soleil. Or, en même temps qu'elle tourne sur elle‑même, la Terre se déplace selon sa trajectoire orbitale dans sa révolution autour du Soleil. Elle doit donc effectuer sur elle‑même une rotation d'angle supérieure à 360° pour que son point pris comme référence se retrouve dans l'axe solaire (cf. la figure ci‑dessous qui, bien évidemment, n'est pas à l'échelle). Le temps nécessaire pour accomplir ce surcroît de rotation est d'environ 4 minutes (soit environ +0,3 % par rapport au jour sidéral). Il en résulte que le jour solaire dure approximativement 24 heures.

(Bien évidemment, le fait qu'un jour solaire dure 24 heures ne doit rien au hasard, puisqu'en fait, l'heure est implicitement définie comme la durée égale à 1/24^e du jour solaire – cf. infra.)

Mais de plus, il faut aussi tenir compte de l'excentricité de l'orbite terrestre autour du Soleil. Même si cette excentricité est assez faible, elle impacte quand même la vitesse de la Terre sur sa trajectoire orbitale – le phénomène ayant une période annuelle.

En effet W :

• au voisinage du périhélie, la plus grande proximité du Soleil induit sur la Terre une accélération radiale plus forte, donc une vitesse plus élevée, donc une trajectoire parcourue plus grande, donc un supplément de rotation plus grand, donc un jour solaire plus long que la moyenne.
• Et au voisinage de l'aphélie, c'est l'inverse : la Terre a une vitesse plus lente, donc un jour solaire plus court que la moyenne.

Par ailleurs, l'inclinaison de l'axe de rotation de la Terre par rapport au plan de l'écliptique induit également une variation du jour solaire, mais selon une période semestrielle : il augmente « autour » des solstices et diminue « autour » des équinoxes W.

Le jour solaire moyen

Toutefois, cette définition s'est révélée quand même insatisfaisante en raison de multiples facteurs.

• D'abord, encore fallait‑il préciser la durée d'une année pour calculer la moyenne ; on verra infra que c'est la notion d'année tropique qui a été retenue.
• Mais surtout, il est apparu que même le jour solaire moyen n'est pas constant d'une année sur l'autre. De nombreux phénomènes astronomiques et géologiques engendrent des perturbations de la fréquence de rotation de la Terre ainsi que sa vitesse orbitale.

Il y a l'influence gravitationnelle de la Lune qui provoque les marées, mais aussi les écoulements des masses atmosphériques (air, eau), les mouvements de la croûte (tectonique des plaques), du magma interne et du noyau liquide. Tous les phénomènes dissipent de l'énergie mécanique et modifient le moment d'inertie de la planète.
• Il y a même l'influence d'autres planètes du système solaire qui, selon leur proximité ou leur éloignement avec la Terre, modifient son accélération.

Certains de ces facteurs sont imprévisibles. Mais sur le très long terme – depuis le tout début de l'histoire de la Terre – on constate un ralentissement, c'est‑à‑dire une augmentation de la période de rotation de la Terre, actuellement de l'ordre de 1,3 ms/j, soit 1 s / 800 j environ.

1. Pour se faire une idée du ralentissement de la rotation de la Terre sur elle‑même, on estime qu'à l'époque du Dévonien, c'est‑à‑dire il y a environ 380 Ma W :
• un jour terrestre durait environ 22 h ;
• et une année environ 400 de ces jours.
2. Et néanmoins, depuis 2020, on observe plutôt une stabilisation de la vitesse de rotation de la Terre sur elle‑même (cf. infra ) – mais il s'agit vraisemblablement d'un épiphénomène.

L'année tropique : période du cycle des saisons

L'année sidérale et l'année tropique

Comme pour la notion de jour, la notion d'année se décline en deux sous‑notions détaillées ci‑dessous

• L'année sidérale W qui est la durée supposée périodique de révolution de la Terre autour du Soleil, lorsqu'elle est observée par rapport aux étoiles. Elle vaut en moyenne 365,25636042 jours solaires moyens.
• L'année tropique W qui est concrètement la durée supposée périodique d'un cycle des quatre saisons, en considérant comme référence de répétition l'équinoxe de printemps de l'hémisphère nord. Elle vaut en moyenne 365,2421898 jours solaires moyens.
En fait, la définition de l'année tropique est plus complexe : c'est la durée moyenne entre deux passages consécutifs du soleil au même point dans son orbite apparente vue depuis la Terre (ce qu'on appelle le cercle écliptique sur la voûte céleste). La définition qui est donnée ci‑dessus correspond en fait à ce qu'on nomme l'année vernale (qui a la même durée que l'année tropique).

Une année tropique est donc plus courte qu'une année sidérale d'environ année 0,01417062 jour, soit 1224,341568 s, autrement dit approximativement 20 min et 24 s.

Un phénomène : la précession des équinoxes

La différence entre les deux notions d'année sidérale et d'année tropique résulte principalement d'un phénomène appelé – par relation de cause à effet – la précession des équinoxes W. C'est ainsi qu'on appelle le mouvement d'oscillation de l'axe de rotation de la Terre – à la manière d'une toupie, mais très lentement puisque la période de cette oscillation est d'environ 25 800 ans.

Ainsi, à la moitié de cette période (donc, tous les 12 900 ans), l'angle que présente l'axe de rotation de la Terre avec la normale au plan de l’écliptique prend une valeur opposée à celle qu'il avait au début de la période. Par exemple :

• à notre époque, le solstice d'hiver de l'hémisphère nord se produit lorsque la Terre est voisine de son périhélie ;
• mais dans environ 12 900 ans, c'est le solstice d'été qui se produira au voisinage du périhélie !

Ce phénomène pourrait sembler négligeable tant sa période est grande à l'échelle de l'histoire contemporaine. Et pourtant, il est identifié comme problématique depuis Hipparque (I^e siècle avant J.‑C. W) ! Et en effet, par la différence de durée entre l'année sidérale et l'année tropique, à chaque siècle, les solstices et équinoxes se décalent de plus d'une journée dans l'année sidérale. C'est ce qu'on appelle la dérive séculaire des saisons.

Choix de l'année tropique pour les calendriers civils

Le calendrier grégorien

Dans le calendrier grégorien, l'année commune W compte 365 j. Et, comme dans le calendrier julien, si le numéro d'année est divisible par 4, on ajoute un jour intercalaire (en anglais, leap day) – le 29 février – et on parle alors d'année bissextile W (en anglais, leap year).

Or cet ajustement n'est pas suffisant puisque, en nombres de jours, la partie fractionnaire de l'année tropique est légèrement inférieure à ¼. En conséquence :

• les années dont le numéro est divisible par 100 (donc par 4) font exception à la règle générale ; elles sont donc considérées comme commune et non pas bissextiles ;
• mais les années dont le numéro est divisible par 400 (donc par 100) font exception à la règle supra ; elles sont bel et bien considérées comme bissextiles et non pas communes.

Le temps universel

Attention. La seconde du temps universel n'a pas exactement (mais presque) la même durée que celle du temps atomique. Elle est définie comme un 86 400^e du jour solaire terrestre moyen, dont la durée est calculée sur la base des chronométrages effectués par le Service international de la rotation terrestre et des systèmes de référence W – en anglais, International Earth rotation and reference systems service ou IERS.

Il en résulte un décalage par rapport au temps atomique international (cf. supra ) de quelques secondes sur une cinquantaine d'années. On va voir que ce décalage est à l'origine de la définition du temps universel coordonné ou UTC (cf. infra ).

Les zones horaires : définition du temps mondial

Lors de la Conférence internationale de Washington W (1884), le méridien de Greenwich W – du nom d'un quartier de Londres où se situe l'Observatoire Royal – a été adopté comme méridien de référence pour définir l'heure internationale. Il sert également à diviser le globe terrestre en deux hémisphères dits Ouest et Est.

Quant aux anciens fuseaux horaires W, ils sont issus d'une division historique du globe en 24 secteurs angulaires réguliers de 15° dont l'un est centré sur le méridien de Greenwich.

Aujourd'hui, on ne parle plus de fuseaux mais de zones horaires W – en anglais, time zone car leur découpage est plus complexe :

• sur la carte mondiale W, on distingue bien 24 grandes zones horaires qui sont chacune étiquetée par un décalage horaire entier positif ou négatif ;
• mais la zone la plus à droite se divise en deux, étiquetées respectivement +12 et −12 ;
• et même, à l'extrême gauche, on observe deux petites zones étiquetées +13 et +14 !
• enfin, certains pays (par exemple, l'Inde…) adoptent un décalage horaire fractionnaire – c'est‑à‑dire qui ne s'exprime pas par un nombre entier d'heures, la résolution autorisée étant de 15 minutes.

Désignation des zones horaires

Pour faciliter les traitements informatiques, certaines zones horaires sont également désignées par un voire plusieurs sigles comme illustré ci‑dessous.

Par exemple :

• WET W pour Western European Time – anciennement Greenwich mean time ou GMT – qui correspond à UTC+0 ;
• CET W pour Central European Time ou WAT pour West Africa Time qui correspondent l'une et l'autre à UTC+1 ;
• EET W pour Eastern European Time ou CAT pour Central Africa Time qui correspondent l'une et l'autre à UTC+2 ; etc.

L'heure d'« été »

Le décalage dit d'heure d'été W  – en anglais, daylight saving time ou DST – consiste à augmenter d'une heure le décalage horaire établi dans une zone horaire durant une période dite estivale (summer time) au sens large. Hors de cette période, on parle d'heure standard (standard time) ou encore d'heure d'hiver.

Il en résulte que :

• le jour de passage à l'heure d'été dure 23 h ;
• le jour de retour à l'heure d'hiver dure 25 h.

Pour faciliter les traitements informatiques, les zones horaires où le décalage d'heure d'été est en vigueur sont désignées par des sigles spécifiques. Par exemple :

• WEST pour Western European Summer Time qui correspond à UTC+1 ;
• CEST pour Central European Summer Time qui correspond à UTC+2 ; etc.

Dans toutes les zones horaires de l'Union Européenne, les règles de changement d'heure sont harmonisées (cf. la carte ci‑dessous, actualisée en 2017) :

• Le passage à l'heure d'été intervient le dernier dimanche du mois de mars à 01:00:00 UTC.
Autrement dit, juste après 00:59:59, l'heure officielle est 02:00:00.
• Le passage à l'heure d'hiver intervient le dernier dimanche du mois d'octobre à 02:00:00 UTC.
Autrement dit, juste après 01:59:59, l'heure officielle est 01:00:00.

Chaque changement d'heure se déroule au même instant quelle que soit la zone horaire, donc avec une ou deux heures de décalage par rapport à l'heure locale. Ainsi, dans la zone horaire d'Europe centrale (CET) :

• le passage à l'heure d'été intervient à 02:00:00 CET qui devient 03:00:00 CEST (Central European Summer Time) ;
• le passage à l'heure d'hiver intervient à 03:00:00 CEST qui redevient 02:00:00 CET (Central European Time).

Le temps universel coordonné

Depuis le 1^er janvier 1972, en plus des 10 secondes additionnelles de rattrapage initial, un total de 27 secondes intercalaires ont été ajoutées à l'UTC, portant le décalage avec le TAI à 37 secondes. Le graphique ci‑contre représente la différence W :
DUT1 = UT1 − UTC
au fil des années depuis 1976, ou chaque pic représente une seconde intercalaire ajoutée par l'IERS.

Conséquences sur les unités de temps

En temps universel coordonné, la seconde et tous ses sous‑multiples ont, comme en temps atomique international, une durée fixe.

En revanche, toutes les unités supérieures – minute, heure, jour, année – n'ont pas toujours la même durée, selon qu'est intervenu ou non l'ajout ou le retrait d'une seconde intercalaire.

• Ainsi, une minute dure presque toujours 60 s mais peut exceptionnellement durer 61 s en cas de seconde intercalaire additionnelle, étant alors comptée de 0 à 60 – cf. l'image ci‑contre.
• En conséquence, l'heure et le jour incluant cette minute durent respectivement 3 601 s et 86 401 s.

Même exceptionnelles, les secondes intercalaires compliquent la détermination d'une date d'arrivée à partir d'une autre date de départ et d'une durée : il faut tenir compte du nombre de secondes intercalaires ajoutées entre ces deux dates et les décompter de la durée pour pouvoir ensuite opérer une division entière de la durée par celle d'une heure normale (3 600 s) ou d'une journée normale (86 400 s).

Représentation du temps calendaire dans les systèmes informatiques

Représentations littérales d'une date (haut niveau)

On rappelle que la représentation littérale d'une information est juste une écriture formelle particulière qui peut s'insérer dans tout type de texte.

Pour éviter les ambiguïtés dans les échanges internationaux, la norme ISO 8601 W (Data elements and interchange formats) spécifie diverses représentations littérales d'une date – au sens large, car ce peut aussi être une heure, voire une date et heure – quelle que soit l'échelle de temps adoptée (UTC, UT1, TAI).

Ces représentations, intelligibles pour l'humain, sont des chaînes de caractères et se déclinent en six formats différents, selon l'unité de résolution choisie – typiquement, le jour pour une date calendaire et la seconde pour une heure civile (cf. la figure donnée à titre d'exemple).

Représentations numériques d'une date (bas niveau)

Et même dans le cas des serveurs de temps, la résolution requise – donc la taille du format – n'est pas la même selon qu'il s'agit :

• d'une machine directement reliée à une horloge atomique – on parle de serveur de stratum 1 (cf. infra ) ;
• ou d'un serveur dans un réseau local – c'est‑à‑dire de stratum supérieur à 1.

Le format timestamp NTP

Pour représenter une date et heure sur l'échelle de l'UTC, le protocole NTP adopte un format décimal non signé à virgule fixe sur 64 bits, appelé timestamp NTP.

Une valeur encodée dans ce format exprime la durée en secondes écoulée depuis depuis le 1^er janvier 1900 à 00 h 00 dans la zone horaire UTC+0 – secondes intercalaires non incluses.

Il s'agit de la date de référence choisie par convention comme instant 0 de l'UTC et appelée en anglais epoch 0.

Le terme « timestamp » fait référence à un outil d'horodatage manuel de documents comme celui en photo ci‑contre (en anglais, stamp signifie « timbre » ou « tampon »).

En français, on pourrait parler d'estampille temporelle W, mais dans la pratique, ce terme n'est pas usité.

Le format timestamp Unix

Les normes POSIX imposent que la partie entière de la date et heure courante soit encodée dans un format différent de celui du timestamp NTP . On parle de format timestamp POSIX, appelé également timestamp Unix W.

Le plus souvent, ce format est implémenté en mémoire par type entier signé sur 32 bits, donc d'étendue comprise entre −2 147 483 648 et +2 147 483 647.

Un timestamp Unix exprime en secondes – mais sans inclure les secondes intercalaires – la durée écoulée depuis le jeudi 1^er janvier 1970 à 00 h 00 exactement dans la zone horaire UTC+0. Cette date est appelée en anglais epoch Unix ou POSIX.

Sur l'Internet, on trouve toutes sortes de page web comme celle‑ci  qui :

• affiche la valeur courante du timestamp Unix ;
• effectue à la demande la conversion au format date et heure d'une valeur de timestamp Unix, et vice‑versa.

Problèmes futurs liés aux représentations numériques des dates

L'un et l'autre de ces bugs annoncés sont bien évidemment anticipés par les concepteurs des systèmes informatiques.

• Un nouveau format date NTP avec une partie entière sur 64 bits a justement été introduit dès 2010 dans la version 4 du protocole NTP pour y remédier (cf. infra). Étant rétrocompatible avec le format précédent, il ne pose pas de gros problèmes de mise en œuvre, et c'est pourquoi on peut considérer qu'il n'y aura pas de bug de l'an 2036.
• Dans le même esprit, les nouvelles versions des systèmes d'exploitation adoptent déjà un format plus large (64 bits) que l'actuel timestamp Unix pour éliminer à très long terme tout risque de débordement. Toutefois, ce nouveau format n'est pas rétrocompatible avec le format précédent à cause du bit de signe, aussi son adoption est complexe et laisse encore ouverte la question du bug de l'an 2038 W.

Le format date NTP

En prévision des besoins futurs en précision et étendue, la version 4 du protocole NTP introduit donc un nouveau format d'encodage élargi – dit date NTP – pour exprimer une date et heure courante de l'échelle de l'UTC. Ce format est conçu pour étendre le précédent format timestamp NTP de façon rétrocompatible (cf. la figure ci‑dessous).

Toutefois, il n'est pas encore utilisé en pratique pour le partage de l'UTC.

Il en résulte que le format date NTP est également décimal à virgule fixe, mais implémenté avec :

• une partie entière encodée sur 64 bits, avec un bit de signe opérant en complément à 2 (cf. chap. C3‑II C) ;
• une partie décimale également encodée sur 64 bits ;

soit une largeur totale de 128 bits (16 octets).

Le signe de la partie entière s'interprète comme suit :

• toute valeur positive correspond à une date et heure ultérieure à la date de référence ;
• toute valeur négative correspond à une date et heure antérieure à la date de référence ;

sachant que la date de référence reste la même que celle du timestamp NTP, à savoir le 1^er janvier 1900 à 00 h 00 dans la zone horaire UTC+0.

Avec une largeur de 64 bits, le format de la partie entière est semblable au type long long du langage C (cf. chap. C3‑II ), qui peut encoder plus de 18 milliards de milliards de valeurs. Cela est largement suffisant pour exprimer plus de 40 fois l'âge actuel de l'Univers W !

Quant à la partie fractionnaire, elle atteint une résolution allant jusqu'à 2⁻⁶⁴ ≃ 5 × 10⁻²⁰ s – laquelle est un million de fois plus petite que la résolution du temps atomique (cf. supra ) !

Soulignons toutefois que même dans sa version v4, le format des messages du protocole NTP ne permet pas de transmettre des données au format date NTP. Ce dernier ne peut servir que pour mémoriser la date et heure courante dans les horloges atomiques.

La notion d'ère

Pour exprimer des dates antérieures ou ultérieures à la période actuelle couverte par le timestamp NTP (du 1^er janvier 1900 au 7 février 2036) mais sans recourir au format date NTP complet, le protocole NTP introduit la notion d'ère – en anglais, era.

Elle consiste à former un ordinal de type entier signé avec les bits 0 à 31 du format date NTP.

Ce numéro d'ère peut prendre des valeurs allant de −2 147 483 648 à 2 147 483 647, chacune désignant une période d'environ 136 ans – soit environ 18 × 10¹⁸ années au total ! Il suffit alors d'associer un numéro d'ère à un timestamp NTP pour reconstituer la partie entière d'une valeur encodée au format date NTP.

Ainsi :

• l'ère 0 correspond à la période actuelle ;
• l'ère −1 correspond à la période allant de l'année 1764 à l'année 1899 ;
• l'ère +1 correspond à la période allant de l'année 2036 à l'année 2172 ;
• etc.

sachant que les changements d'ère se produisent en cours d'année (et même de journée…).

Toutefois, même dans sa version v4, le format des messages du protocole NTP ne permet pas de transmettre des données d'ère.

Prise en compte des secondes intercalaires

Pour bien comprendre ces deux aspects, il faut étudier en détail la gestion des secondes intercalaires avec les échelle de temps TAI et UTC.

Cas d'une seconde ajoutée

Prenons l'exemple de la seconde intercalaire qui a été ajoutée le 30 juin 2015, détaillée sur la figure ci‑dessous.

• Sur l'échelle du TAI (temps atomique international), le compteur des secondes écoulées depuis le 1^er janvier 1900 est incrémenté régulièrement.
• En revanche, sur l'échelle de l'UTC, le compteur des secondes que constitue la partie entière du timestamp NTP est comme figée durant une seconde à la valeur 3644697600.
Durant cette seconde intercalaire insérée, bien visible graphiquement, l'horloge officielle affiche l'heure exceptionnelle 23:59:60.
• Au passage, la différence TAI − UTC augmente d'une unité : elle passe de 35 à 36.

En définitive, on constate que deux secondes différentes du TAI correspondent à une même valeur du timestamp NTP. Pour conserver une relation d'ordre total sur ces valeurs, on doit donc distinguer deux échelles, avant et après l'ajout de la seconde intercalaire.

On peut également observer qu'à l'heure remarquable 00:00:00 du 01/07/2015, la valeur 3644697636 du timestamp TAI n'est pas un multiple de 86 400 (la durée d'un jour en secondes). Il n'y a donc pas d'algorithme simple pour établir la correspondance entre le TAI et le temps calendaire.

Pour une compréhension plus fine de l'ajout d'une seconde intercalaire, il est pertinent de le schématiser sur un diagramme bidimensionnel, avec en abscisse le TAI et en ordonnée l'UTC, comme ci‑dessous.

• En règle générale, la relation entre les deux échelles est une droite à 45°, puisque chaque incrémentation sur l'une opère également sur l'autre de façon synchrone.
• Mais lors de l'ajout d'une seconde intercalaire, un décalage vers la droite apparaît. Durant cette seconde, le timestamp NTP est figé.
En revanche, on opère une technique différente pour le timestamp Unix : ce dernier est décrémenté juste avant le début de la seconde intercalaire, puis incrémenté normalement, comme toutes les secondes.

Cas d'une seconde retranchée

La suppression d'une seconde intercalaire n'ayant jamais été effectuée depuis l'adoption du temps universel coordonné, il n'y a donc pas d'exemple réel sur lequel se baser comme on vient de le faire pour une seconde additionnelle. On peut toutefois raisonner avec des valeurs génériques de timestamp sur les échelles du TAI et de l'UTC au moment de la suppression, qu'on note respectivement  n et m, comme sur la figure ci‑dessous.

• Sur l'échelle du TAI, le timestamp est incrémenté normalement lors de la suppression de la seconde intercalaire, sans aucune irrégularité.
• En revanche, sur l'échelle de l'UTC, le timestamp NTP est incrémenté de deux unités à la fin de la seconde m − 2 et passe donc directement à la valeur m sans passer par m − 1.
Ici, la seconde intercalaire ne peut pas être représentée graphiquement puisqu'elle est soustraite (en quelque sorte, elle n'existe pas).

Pour ne pas avoir une irrégularité d'échelle résultant de cette double incrémentation, il est nécessaire là aussi de distinguer deux échelles, avant et après la suppression de la seconde intercalaire.

Prise en compte des zones horaires et de l'heure d'été

Partage du temps universel coordonné

Généralités

Le partage de l'UTC sur un réseau – en particulier via l'Internet – peut s'effectuer par l'intermédiaire de divers protocoles applicatifs (c'est‑à‑dire appartenant à la couche n° 7 du modèle OSI). Le choix du protocole dépend des besoins en précision, mais aussi des contraintes de sécurité.

Développé au milieu des années 1980, le protocole NTP W (network time protocol) est de loin le plus utilisé pour le partage du temps. Sa dernière version – v4, basée sur la RFC 5905  publiée en 2010 – tend à se généraliser progressivement dans les systèmes d'exploitation des machines.

Initié par les travaux du Pr. David Mills W qui a accompli l'essentiel de sa carrière à l'Université du Delaware (USA), le protocole NTP est étonnamment complexe au regard de l'apparente simplicité de son objectif principal : partager le timestamp de la date et heure courante sur l'échelle de l'UTC.

Cette complexité s'explique par le fait :

• que la donnée partagée est constamment changeante ;
• que pour garantir une précision meilleure que la seconde, il faut tenir compte des délais de transmission sur le réseau, qui sont très contextuels selon le client, le serveur et la distance qui les sépare ; ces délais constituent un facteur d'erreur significatif ;
• qu'il existe par ailleurs de très nombreuses causes de déréglage des horloges (dérive, défaillance d'un composant, défaut d'alimentation…) ; en conséquence, la consultation d'une seule horloge ne garantit pas toujours une précision satisfaisante de la date et heure courante transmise.

Architecture des serveurs NTP

Différents cas de figures selon le réseau local

• Dans les cas les plus simples (collectivités, administrations, petites entreprises sans besoins spécifiques), il suffit simplement de paramétrer les systèmes d'exploitation des machines pour qu'ils se synchronisent régulièrement sur des serveurs de temps publics sur l'Internet.
Avec le protocole NTP, la précision usuelle obtenue est de l'ordre de la seconde, mais il n'est pas exclu qu'une machine soit parfois désynchronisée, en particulier si elle est restée longtemps hors‑service.
• Dans des contextes qui requièrent une précision meilleure que la seconde et/ou avec une grande fiabilité, un ou plusieurs serveurs de temps dédiés, avec plusieurs sources de synchronisation redondantes (Internet, satellite, radio) sont nécessaires.
La figure ci‑dessous illustre une architecture possible pour de tels contextes comme par exemple la production manufacturière soumise à une réglementation stricte (industrie pharmaceutique, etc.), la vidéo surveillance de lieux sensibles (centres de détention, banques, etc.), les requêtes sur des bases de données partagées très précises (opérations sur les marchés financiers…), etc.

Machine dédiée serveur de temps

Une machine dédiée en serveur de temps W est une machine serveur (en général, de type rack) qui dispose :

• d'un circuit d'horloge interne très précis ;
• d'un ou plusieurs plusieurs moyens de synchronisation (liaison directe à une horloge atomique, antenne satellite, antenne radio) sur des références de temps classifiées stratum 0 ;
• d'une ou plusieurs interfaces réseau très rapides pour pouvoir partager sa date et heure courante avec de bonnes performances.

Très souvent, elle est aussi dotée d'une interface utilisateur avec un afficheur pour visualiser la date et l'heure courante.

De plus, elle doit exécuter en tâche de fond un composant logiciel qui met en œuvre un protocole de partage de temps en qualité de serveur, typiquement NTP.

Aspects logiciels généraux du protocole NTP

Le protocole NTP adopte un format de message unique, quel quel soit le mode d'association et quel que soit le rôle de la machine dans ce mode. Ce format est détaillé en figure ci‑contre de façon classique par un tableau d'une suite de mots de 4 octets (32 bits).

Un message NTP se divise en deux parties :

• un en‑tête de 48 octets, comprenant diverses informations administratives, suivies par 4 champs de 8 octets chacun (64 bits) pour y inscrire respectivement 4 timestamp (ref, org, rec, xmt) ;
• une partie optionnelle constituée potentiellement de deux champs d'extension, chacun de taille variable, et toujours suivis :
• d'une clef d'identification de 32 bits ;
• d'un message d'authentification de 128 bits dit MAC (pour message authentication code).

uint32_t NTPpacket::decodeTimestamp(int8_t byteOffset)
{
  uint32_t ntpTimestamp = 0;
  for (int8_t byteRank = 0, bitShift = 24; byteRank <= 3; byteRank++, bitShift -= 8) {
    ntpTimestamp |= (uint32_t(ntpMessage[byteOffset + byteRank])) << bitShift;
  }
  return ntpTimestamp;
}

    uint32_t xmtTimestamp = decodeTimestamp(XMT_BYTE);

float NTPpacket::decodeFracTimestamp(int8_t byteOffset)
{
  uint32_t ntpFracTimestamp = 0;
  for (int8_t byteRank = 0, bitShift = 24; byteRank <= 3; byteRank++, bitShift -= 8) {
    ntpFracTimestamp |= (uint32_t(ntpMessage[byteOffset + byteRank])) << bitShift;
  }
  float frac = 0.0;
  for (int8_t bitRank = 31; bitRank >= 0; bitRank--) {
    frac += ((ntpFracTimestamp >> bitRank) & 0b1) * pow(2, bitRank - 32);
  }
  return frac;
}

  float    xmtFrac      = decodeFracTimestamp(XMT_BYTE + 4);

Protocole d'échange de messages NTP

Dans le cas d'un mode d'association client‑serveur, le déroulement du protocole NTP se réduit à l'échange de deux messages : une requête du client (message de mode 3) suivie d'une réponse du serveur (message de mode 4). Avec un algorithme de traitement suffisamment bien pensé, en exploitant :

• les timestamp ref, rec et xmt transmis dans le message de réponse d'une part,
• et la connaissance des instants d'émission t₁ de la requête et de réception t₂ de la réponse d'autre part,

le client doit être en mesure de se synchroniser sur l'échelle de l'UTC avec un écart de précision inférieur à ±0,2 s – ces écarts étant dus aux incertitudes de temps de transmission entre le client et le serveur.

Lors d'une première synchronisation, le client ne dispose a priori d'aucune référence temporelle calendaire. En conséquence, tous les timestamp de son message de requête sont mis à zéro.

Lors de la réception de la réponse du serveur, le client doit effectuer les traitements suivants pour se synchroniser à la date et heure courante de l'UTC.

• Il doit utiliser son temps processeur pour chronométrer précisément la durée Δt = t₂ − t₁ entre :
• l'instant t₁ d'envoi du message de requête ;
• l'instant t₂ de réception du message de réponse.
• Il doit calculer la durée Δt' = t'₂ − t'₁ entre :
• l'instant t'₁ de réception par le serveur du message de requête, codé dans le timestamp rec (received) ;
• l'instant t'₂ d'envoi par le serveur du message de réponse, codé dans le timestamp xmt (emitted)

En faisant l'hypothèse que les temps de transmission aller et retour entre le client et le serveur sont égaux, le client peut alors immédiatement synchroniser son horloge avec ce qui constituera son nouveau timestamp de référence :
t_ref = t'₂ + (Δt − Δt') / 2

La tz database

La tz databate W – aussi dite zoneinfo – est une base de données collaborative multi‑format qui collectionne toutes les informations historiques sur la gestion du temps calendaire dans tous les pays du globe.

Librement accessible sur le site de l'Iana , elle met également à la disposition de tout internaute le code source de nombreuses fonctions pour implémenter la gestion du temps calendaire dans les systèmes d'exploitation des machines.

Focalisée prioritairement sur la période récente écoulée depuis le 1^er janvier 1970 (Unix Epoch), elle réunit également beaucoup d'informations plus anciennes.

Gestion informatique du temps et manipulation des données calendaires

Manipulations sous Linux

Accès aux paramètres de date et heure courante – réglages temporels du système

Si le système d'exploitation de la machine est dotée d'un bureau, l'affichage de la date et heure courante est prévu par défaut – typiquement, dans un coin du tableau de bord (barre de tâche). En cliquant sur cette zone, on accède à des réglages élémentaires via une fenêtre graphique, comme on peut le voir sur la capture d'écran ci‑contre pour le système Linux Mint / Cinnamon. Il est ainsi possible :

• de choisir la zone horaire, en sélectionnant la région continentale du globe et la capitale régionale de la zone ;
• d'activer/désactiver la synchronisation réseau ;
• ou si la synchronisation réseau est désactivée, de régler la date et heure à une valeur choisie ;
• de paramétrer quelques aspects du format d'affichage de la date et heure.

Toutefois, il n'est pas possible de paramétrer le choix du serveur de temps ou la fréquence de synchronisation.

Sur les distributions de Linux mettant en œuvre le daemon systemd – Linux Mint, par exemple – la commande timedatectl  permet notamment :

• sans option ni argument, d'afficher les informations essentielle sur la date et heure courante et les réglages du système ; par exemple, on peut typiquement obtenir une sortie comme :

	
timedatectl
	
               Local time: dim. 2023-01-22 00:36:31 CET
           Universal time: sam. 2023-01-21 23:36:31 UTC
                 RTC time: sam. 2023-01-21 23:36:31
                Time zone: Europe/Paris (CET, +0100)
System clock synchronized: yes
               TP service: active
          RTC in local TZ: no
	

• avec la commande secondaire set-time suivie d'un argument de la forme "yyyy-mm-dd hh:mm:ss", de régler la date et heure courante à la valeur ainsi codée.
• avec la commande secondaire set-timezone suivie d'un argument de la forme "region/place", de régler la zone horaire ainsi codée ;
• avec la commande secondaire set-ntp suivie d'un argument booléen (1 ou 0), de respectivement activer/désactiver la synchronisation du système avec un serveur de temps ;
avec la commande secondaire timesync-status sans argument, d'afficher les informations essentielles sur la synchronisation du système avec un serveur de temps ; par exemple, on peut typiquement obtenir une sortie comme :

	
timedatectl timesync-status
	
       Server: 2620:2d:4000:1::41 (ntp.ubuntu.com)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
        ratum: 2
    Reference: A71C1419
    Precision: 1us (-25)
Root distance: 1.174ms (max: 5s)
       Offset: +358us
        Delay: 25.992ms
       Jitter: 20.304558s
 Packet count: 19
    Frequency: -11,348ppm
	

Le fichier de configuration /etc/systemd/timesyncd.conf code la configuration par défaut effectuée par compilation. Dans l'exemple ci‑dessous, certaines lignes ont été décommentées pour être prises en compte.

NTP=fr.pool.ntp.org
FallbackNTP=ntp.ubuntu.com time.nist.gov
#RootDistanceMaxSec=5
PollIntervalMinSec=64
PollIntervalMaxSec=4096

Pour que les modification à ce fichier soient effectives, il faut redémarrer le service systemd-timesyncd.

sudo systemctl restart systemd-timesyncd
timedatectl timesync-status
       Server: 162.159.200.1 (fr.pool.ntp.org)
Poll interval: 2min 8s (min: 1min 4s; max 1h 8min 16s)
         Leap: normal
      Version: 4
      Stratum: 3
    Reference: A1A0804
    Precision: 1us (-25)
Root distance: 11.772ms (max: 5s)
       Offset: +803us
        Delay: 19.890ms
       Jitter: 0
 Packet count: 1
    Frequency: -11,563ppm

Manipulations en langages C/C++

Toutes ces fonctionnalités sont complexes et il n'est pas envisageable de les traiter en exhaustivité dans ce chapitre. Seuls quelques rudiments et exemples académiques sont donnés ci‑après. Pour plus de détails, on pourra se reporter à cet article .

Principaux types du temps calendaire

Chacun de ces deux types a ses usages privilégiés :

• Le type time_t est incontournable pour mémoriser une date et heure UTC à partir de celle du système (à l'aide de la fonction time – cf. infra) ou de la partie entière du timestamp NTP transmis par un serveur de temps.

Si ntpNow est une variable de type uint32_t mémorisant la partie entière du timestamp NTP transmis par un serveur de temps, on peut déclarer une variable mémorisant le timestamp Unix correspondant par le code ci‑dessous :

  const uint32_t unixEpoch = 2208988800;
  time_t unixNow = ntpNow - unixEpoch;

Le type time_t peut aussi être utilisé pour effectuer des calculs de durée entre deux dates directement par soustraction, ou pour déterminer une date et heure à partir d'une autre avec un décalage – par addition ou soustraction – d'une durée exprimée en secondes ou d'autres unités à nombre de secondes fixe : la minute (60 s), l'heure (3600 s), le jour (86400 s) mais pas le mois ni l'année.

Pour déterminer une date et heure D₂ fixée 100 jours après une date et heure D₁ définie par son timestamp Unix t1, il suffit de calculer le timestamp Unix t2 par une instruction comme :

  t2 = t1 + 86400 * 100

• Le type tm est incontournable pour mémoriser toute date et heure calendaire particulière. Il suffit juste d'adapter la valeur de chaque champ compte‑tenu de son intervalle de valeurs nominales.

On peut mémoriser la date et heure de signature de l'Armistice de la première guerre mondiale – le 11 novembre 1918 à 5 h 15 W – dans la variable armistice par le code suivant :

  struct tm armistice = {
    .tm_sec   = 0,
    .tm_min   = 15,
    .tm_hour  = 5,
    .tm_mday  = 11,
    .tm_mon   = 10, // november (0 = January)
    .tm_year  = 18  // 1918
  };

sachant qu'il n'est pas indispensable de coder les valeurs pour les autres champs – ils peuvent être automatiquement calculés grâce à la fonction mktime (cf. infra).

1. Déterminer dans le type time_t la valeur du timestamp Unix d'une date et heure calendaire serait beaucoup moins commode : il faudrait calculer le nombre de seconde séparant cette date du 1^er janvier 1970.
2. On va voir infra que le type tm est également commode pour déterminer une date à partir d'une autre avec un décalage d'une durée exprimée dans n'importe quelle unité – notamment les mois et années, ce qui n'est pas commode avec le type time_t.

Principales fonctions de manipulation du temps calendaire

Les fonctions qui sont présentées ci‑après sont les plus usuelles. On donne leur prototype précédé d'un commentaire qui explique la signification de leur nom.

1. // current time
   time_t time(time_t * arg);
   

   La fonction time C retourne la valeur du timestamp Unix correspondant à la date et heure courante fournie lors de l'exécution par le système d'exploitation de la machine cible sur laquelle le programme s'exécute, dans la zone horaire UTC+0.
L'argument formel arg peut être le pointeur NULL (c'est le cas usuel), sinon un pointeur sur une variable déclarée de type time_t qui prend alors la valeur retournée par la fonction (par déréférencement, cf. chap. C5‑I ).
En cas d'erreur (typiquement, pas de timestamp Unix fourni par le système), la fonction retourne la valeur (time_t) (-1), c'est‑à‑dire -1 si le type time_t est implémenté signé, sinon la valeur maximale encodable dans ce type (par rebouclage cyclique).

Le programme ci‑dessous code la déclaration d'une variable systNow de type time_t et son initialisation par appel de la fonction time pour lui donner la valeur du timestamp Unix de la date et heure courante de l' UTC du système.

#include <stdio.h>
#include <time.h>

int main(void)
{
  time_t systNow = time(NULL);
  printf("Unix timestamp now: %ld\n", systNow);

  return 0;
}

Exécuté sur OnlineGDB le 20 janvier 2023 à 12:06:40 UTC, ce programme a produit l'affichage :

Unix timestamp now: 1674216400

Remarque. On aurait pu aussi coder la ligne nº 6 par :

  time_t systNow = 0;  time(&systNow);

2. // GMT time
   struct tm * gmtime(const time_t * timer);
   

   La fonction gmtime C effectue la conversion du timestamp Unix passé par l'argument timer (un pointeur sur donnée de type time_t) en une valeur structurée de type tm, retournée via un pointeur sur une variable préalablement déclarée de ce type. Elle opère sans décalage de zone horaire, c'est‑à‑dire en restant dans la zone horaire UTC+0 (anciennement GMT).

Le programme ci‑dessous code la déclaration d'une variable structurée tmThen de type tm et son initialisation par appel de la fonction gmtime avec pour argument effectif l'adresse de la variable then, un timestamp Unix dont la valeur correspond à la date et heure calendaire du vendredi 20 janvier 2023, 12:06:40 UTC (cf. l'exemple précédent supra ).

Les instructions suivantes (lignes nº 8 à 13) codent l'affichage des différents champs de la variable tmThen pour vérification.

#include <stdio.h>
#include <time.h>

int main(void)
{
  time_t then = 1674216400; // i.e. Jan. 20th 2023, 12:06:40 UTC+0
  struct tm tmThen = *gmtime(&then);

  printf("tm_hour: %2d \t tm_min:  %2d \t tm_sec:   %3d\n", 
          tmThen.tm_hour,  tmThen.tm_min, tmThen.tm_sec);
  printf("tm_mday: %2d \t tm_mon:  %2d \t tm_year:  %3d\n", 
          tmThen.tm_mday, tmThen.tm_mon, tmThen.tm_year);
  printf("tm_wday: %2d \t tm_yday: %2d \t tm_isdst: %3d\n",
          tmThen.tm_wday, tmThen.tm_yday, tmThen.tm_isdst);

  return 0;
}

Exécuté sur OnlineGDB, ce programme produit en sortie standard l'affichage suivant :

tm_hour: 12      tm_min:   6      tm_sec:    40
tm_mday: 20      tm_mon:   0      tm_year:  123
tm_wday:  5      tm_yday: 19      tm_isdst:   0

Et conformément aux propriétés du type tm (cf. supra ), on observe que :

• le champ tm_mon ne vaut pas 1 mais 0 (la numérotation des mois commence à l'indice 0) ;
• le champ tm_year ne vaut pas 2023 mais 123 (nombre d'années écoulées depuis 1900) ;
• le champ tm_wday vaut 5 car le premier jour de la semaine est le dimanche, numéroté 0 ;
• le champ tm_isdst vaut 0 car en janvier, l'heure d'été n'est pas bien évidemment pas active.

3. // local time (in the timezone defined by the locale)
   struct tm * localtime(const time_t * timer);
   

   La fonction localtime C effectue la même conversion que la fonction gmtime, mais en opérant un décalage dans la zone horaire définie dans l'environnement d'exécution du programme – par défaut, celle du système d'exploitation.

En prolongement des exemples précédents, le programme ci‑dessous initialise la variable structurée tmNowLocal de type tm avec un appel de la fonction localtime. Elle lui affecte la date et heure définie par le timestamp Unix then (20 janvier 2023, 12:06:40 UTC) mais décalée dans la zone horaire du système et en tenant compte de la valeur du paramètre DST (dayligth saving time).

#include <stdio.h>
#include <time.h>

int main(void)
{
  time_t then = 1674216400; // i.e. Jan. 20th 2023, 12:06:40 UTC+0 
  struct tm tmThenLocal = *localtime(&then);

  printf("tm_hour: %2d \t tm_min:  %2d \t tm_sec:   %3d\n", 
          tmThenLocal.tm_hour,  tmThenLocal.tm_min, tmThenLocal.tm_sec);

  return 0;
}

Compilé et exécuté sur un poste de travail en France métropolitaine – zone horaire CET, soit UTC+1 – il produit en sortie standard l'affichage suivant :

tm_hour: 13      tm_min:   6      tm_sec:    40

où l'on voit que le champ tm_hour de la variable tmThenLocal a pris la valeur 13 conformément au décalage horaire de +01:00 par rapport à l'UTC.

4. // make time
   time_t mktime(struct tm * arg);
   

   La fonction mktime C effectue la conversion inverse de celle opérée par les fonctions gmtime et localtime. À partir d'une date et heure locale encodée dans une variable de type structuré tm, pointée par son argument arg, elle retourne une valeur de timestamp Unix. Elle tient compte de l'éventuel décalage de zone horaire et du paramètre DST définis dans l'environnement d'exécution du programme (par défaut, les réglages du système).

En prolongement des exemples précédents, le programme ci‑dessous code deux affectations successives à la variable then de type time_t par appel de la fonction mktime :

• d'abord en pointant sur la variable structurée tmThenLocal qui mémorise la date et heure locale correspondant au timestamp Unix 1674216400 (20 janvier 2023, 12:06:40 UTC) ;
• puis en pointant sur la variable structurée tmThen qui mémorise la date et heure UTC correspondant au même timestamp Unix.

#include <stdio.h>
#include <time.h>

int main(void)
{
  time_t then = 1674216400; // i.e. Jan. 20th 2023, 12:06:40 UTC+0 
  struct tm tmThenLocal = *localtime(&then);
  struct tm tmThen      = *gmtime(&then);

  then = mktime(&tmThenLocal);
  printf("then: %lu\n", then);
  
  then = mktime(&tmThen);
  printf("then: %lu\n", then);

  return 0;
}

Compilé et exécuté sur un poste de travail sous Linux situé en France métropolitaine – zone horaire CET, soit UTC+1 – il produit en sortie standard l'affichage suivant :

then: 1674216400
then: 1674212800

où l'on observe que la valeur originale du timestamp then :

• a, dans le premier cas, été correctement restituée, puisque issue d'une heure locale (la valeur de tmThenLocal) ;
• a, dans le deuxième cas, été diminuée de 3600, soit la valeur du décalage horaire de la zone, puisque issue d'une heure UTC (la valeur de tmThen).

Il apparaît donc clairement qu'à l'exécution, une date et heure mémorisée dans une variable structurée de type tm est toujours considérée comme locale par la fonction mktime pour déterminer le timestamp correspondant. En effet, le type tm ne comporte aucun champ de zone horaire. Seul le paramètre DST est mémorisé.

Remarque. Les champs tm_wday et tm_yday sont ignorés pour le calcul de la valeur de retour de la fonction mktime. Cette dernière se base uniquement sur les composantes calendaires qui définissent une date et heure de façon usuelle, c'est‑à‑dire avec l'année, le mois, le jour, les heures, les minutes et les secondes.

5. // string from time
   size_t strftime(char * str, size_t count, const char * format, const struct tm * arg);
   

   La fonction strftime C est une fonction complexe de transcription :
• dans une chaîne de caractères – l'argument str,
• conformément aux spécifications de transcription d'une chaîne de format – l'argument format,
• et dans la limite d'un nombre d'octets – l'argument count,
• de la date et heure mémorisée dans l'argument arg qui est un pointeur sur type structuré tm.
Elle retourne le nombre d'octets effectivement écrits dans la chaîne str.
Les spécifications de transcription de la chaîne format présentent des similitudes avec les spécifications de conversion des fonctions printf et scanf du module de bibliothèque stdio du langage C (cf. chap. C2‑VII C). Mais au delà du recours à la syntaxe %caractère‑code, ce ne sont pas les mêmes spécifications, tout simplement parce qu'elles ciblent des valeurs numériques de types temporels (heures, minutes, secondes, etc.). On peut consulter ces spécifications sur cette page web de référence C.

Reprenons l'exemple précédent qui a servi à illustrer la fonction gmtime (cf. supra ) avec la date et heure calendaire du vendredi 20 janvier 2023, 12:06:40 UTC mémorisée dans la variable tmThen de type structuré tm. C'est ce qu'on retrouve aux lignes nº 6 & 7 du programme ci‑dessous.

À la ligne nº 8, on déclare une variable de type chaîne de caractère pour pouvoir mémoriser l'effet de la fonction strftime. On appelle alors cette dernière successivement 3 fois pour illustrer diverses spécifications de transcription parmi toutes celles possibles.

#include <stdio.h>
#include <time.h>

int main(void)
{
  time_t then = 1674216400; // i.e. Jan. 20th 2023, 12:06:40 UTC+0
  struct tm tmThen = *gmtime(&then);
  char stringThen[50] = "";
  
  strftime(stringThen, sizeof stringThen, "%FT%T%z", &tmThen);
  printf("%s\n", stringThen);

  strftime(stringThen, sizeof stringThen, "%c", &tmThen);
  printf("%s\n", stringThen);

  strftime(stringThen, sizeof stringThen, "%A, %B %d, %Y, %R %Z", &tmThen);
  printf("%s\n", stringThen);
  
  return 0;
}

Compilé et exécuté sur un poste de travail sous Linux situé en France métropolitaine, ce programme produit en sortie standard l'affichage suivant :

2023-01-20T12:06:40+0000
Fri Jan 20 12:06:40 2023
Friday, January 20, 2023, 12:06 GMT

où l'on peut observer l'effet des différentes chaînes de format :

• "%FT%T%z" code un format conforme à la norme ISO 8601 (remarque : le séparateur T est inséré entre les spécifications %F et %T) ;
• "%c" code un format abrégé d'usage courant dans le monde anglo‑saxon (la zone horaire n'étant pas précisée) ;
• "%A, %B %d, %Y, %R %Z" code un format long sur mesure, là encore usuel dans le monde anglo‑saxon.

Il est également possible d'obtenir un formatage conforme à la langue locale en codant le programme modifié comme ci‑dessous :

#include <stdio.h>
#include <time.h>
#include <locale.h>

int main(void)
{
  setlocale(LC_TIME, "fr_FR.utf-8");

  time_t then = 1674216400; // i.e. Jan. 20th 2023, 12:06:40 UTC+0
  struct tm tmThen = *gmtime(&then);
  char stringThen[50] = "";

  strftime(stringThen, sizeof stringThen, "%FT%T%z", &tmThen); // unchanged
  printf("%s\n", stringThen);
  
  strftime(stringThen, sizeof stringThen, "%c", &tmThen);      // unchanged
  printf("%s\n", stringThen);
  
  // format string changed below
  strftime(stringThen, sizeof stringThen, "%A %d %B %Y, %R %Z", &tmThen); 
  printf("%s\n", stringThen);
  
  return 0;
}

L'affichage devient alors conforme aux usages en France :

2023-01-20T12:06:40+0000
ven. 20 janv. 2023 12:06:40
vendredi 20 janvier 2023, 12:06 GMT

Remarque. En ligne nº 7, l'appel de la fonction setlocale affecte au paramètre régional LC_TIME la valeur "fr_FR.utf-8" dans l'environnement d'exécution du programme (par défaut, ce paramètre prend la valeur "C" comme tous les autres paramètres régionaux – cf. chap. C3‑VIII , quels que soient les valeurs des paramètres du système). Ce changement ne produit aucun décalage d'heure pour tenir compte de la zone horaire du système mais cela modifie seulement le format d'affichage.

6. // string parsed time
   char * strptime(char * str, const char * format, struct tm * arg);
   

   La fonction strptime C est une fonction complexe de transcription inverse de celle opérée par la fonction strftime. Elle effectue l'analyse (parsing) :
• d'une chaîne de caractère formatée exprimant un ou plusieurs éléments de date et heure – l'argument str,
• avec un format codé avec des spécifications de transcription une chaîne de format – l'argument format,
et mémorise ces éléments dans une donnée structurée de type structuré tm accédée par pointeur – l'argument arg.
Les spécifications de transcription sont sensiblement les mêmes que celles employées par la fonction strftime.
Attention ! La fonction strptime n'est pas incluse dans la bibliothèque standard du langage C mais elle fait partie des outils complémentaires GNU. Pour l'utiliser, il est nécessaire de coder au début du programme la direction :
#define _GNU_SOURCE

Pour donner un emploi typique de la fonction strptime, reprenons l'exemple précédent en sens inverse.

• À la ligne nº 7, on commence par déclarer une chaîne de caractère nommée stringThen initialisée avec la date et heure du 20 janvier 2023, 12:06:40 UTC, composée dans le format de la norme ISO 8601.
• À la ligne nº 8, on déclare une variable structurée nommée tmThen de type tm, dont tous les champs sont initialisée à 0.
• À la ligne nº 10, on appelle la fonction strptime avec pour deuxième argument effectif la chaîne de format "%FT%T%z".
• Les lignes nº 12 à 17 permettent d'afficher les valeurs de tous les champs de la variable tmThen.

#define _GNU_SOURCE
#include <stdio.h>
#include <time.h>

int main(void)
{
  char stringThen[] = "2023-01-20T12:06:40+0000";
  struct tm tmThen = {0};

  strptime(stringThen, "%FT%T%z", &tmThen);
  
  printf("tm_hour: %2d \t tm_min:  %2d \t tm_sec:   %3d\n", 
          tmThen.tm_hour,  tmThen.tm_min, tmThen.tm_sec);
  printf("tm_mday: %2d \t tm_mon:  %2d \t tm_year:  %3d\n", 
          tmThen.tm_mday, tmThen.tm_mon, tmThen.tm_year);
  printf("tm_wday: %2d \t tm_yday: %2d \t tm_isdst: %3d\n",
          tmThen.tm_wday, tmThen.tm_yday, tmThen.tm_isdst);
  
  return 0;
}

Sans surprise, on obtient en sortie standard l'affichage attendu suivant:

tm_hour: 12      tm_min:   6     tm_sec:    40
tm_mday: 20      tm_mon:   0     tm_year:  123
tm_wday:  5      tm_yday: 19     tm_isdst:   0

Manipulations dans l'environnement Arduino

Le module Time

Dans l'environnement Arduino, les modules time et ctime des bibliothèques standards des langages C/C++ sont difficilement utilisables (en particulier sur les cartes à cœur AVR – Uno, Nano, Mega, etc.). En effet, en l'absence de système d'exploitation pour entretenir un temps calendaire, il faut en implémenter un à l'aide de la fonction millis – cf. chap. C2‑IX C.

Dans le module Time, on trouve essentiellement deux types :

• le type scalaire time_t (synonyme de unsigned long – 32 bits quel que soit le modèle de carte Arduino) ;
ce format est choisi pour être polyvalent dans la mesure où il permet d'encoder aussi bien :
• une partie entière de timestamp NTP ;
• les valeurs positives de timestamp Unix ;
• le type structuré tmElements_t, similaire au type tm du C/C++ mais avec seulement 7 champs – le paramètres DST n'étant malheureusement pas inclus.

On trouve également de nombreuses fonctions :

• La fonction now retourne la valeur de la date et heure courante mémorisée sous la forme d'un timestamp Unix.
• Les fonctions hour, minute, second, day, weekday, month et year, retournent respectivement l'heure, les minutes, les secondes, le jour du mois, le jour de la semaine, le mois et l'année correspondant à un timestamp Unix passé en argument.
De plus, lorsque l'argument est omis, c'est la valeur du timestamp courant (délivré par la fonction now) qui est considéré. Autrement dit, un appel comme hour() donne la valeur de l'heure courante.
• La fonction setTime règle la date et heure courante de la carte à partir de la valeur d'un timestamp Unix passé comme argument.

Le paramètre DST n'est pas pris en charge dans le module Time mais il existe d'autres modules de bibliothèque qui permettent de gérer cet aspect, notamment Timezone, décrit ci‑dessous.

Le module Timezone

Pour mettre en œuvre le module Timezone dans un programme, il est tout d'abord nécessaire de déclarer deux variables globales (ou deux variables locales mais statiques) de type structuré TimeChangeRule. Ces deux variables définissent respectivement le passage de l'heure d'hiver à l'heure d'été et vice‑versa. L'une et l'autre sont à initialiser par une liste qui comprend dans l'ordre :

• l'appellation de la zone horaire après changement (une chaîne de 5 caractères maximum, par exemple WET, CET, etc.) ;
• le moment du changement, défini par :
• la semaine dans le mois (l'une des constantes énumérées First, Second, Third, Fourth, Last) ;
• le mois (l'une des constantes énumérées Jan, Feb, etc.) ;
• l'heure (un nombre entier, par exemple 2) ;
• le décalage horaire par rapport à l'UTC exprimé en minutes (un nombre entier signé, par exemple +60 pour le décalage UTC+1).

  static TimeChangeRule localDST = {"CEST", Last, Sun, Mar, 2, +120};   
  static TimeChangeRule localSTD = {"CET",  Last, Sun, Oct, 3,  +60};

Ensuite, on doit déclarer une objet global de la classe Timezone via son constructeur, en passant comme argument les valeurs des deux variables de changement d'heure préalablement déclarées. On peut alors disposer des méthodes toLocal et toUTC de cette classe pour obtenir :

• le timestamp déterminant la date et heure locale dans la zone horaire prenant en compte l'éventuelle heure d'été à partir du timestamp correspondant de l'UTC ;
• et vice‑versa.

Ce timestamp est utilisable comme n'importe quel autre pour régler l'heure sur la carte Arduino à l'aide de la fonction setTime du module Time (cf. supra ).

  static Timezone localTZ(localDST, localSTD);
  time_t localTimestamp = localTZ.toLocal(utc);

Les modules de client NTP