référentiel informatique de mesure du temps De Wikipédia, l'encyclopédie libre
L'heure Unix ou heure Posix est une mesure du temps fondée sur le nombre de secondes écoulées depuis le 00:00:00 UTC, hors secondes intercalaires. Elle est utilisée principalement dans les systèmes qui respectent la norme POSIX[1], dont les systèmes de type Unix, d'où son nom. C'est la représentation POSIX du temps.
L'heure Unix courante 1730717168 (rafraîchir) (ISO 8601: 2024-11-04T10:46:08Z)
NB: cette date du « 00:00:00 UTC» est appelée «époque Unix».
La définition ci-dessus signifie que l'heure Unix ou heure Posix n'est pas égale à la durée exacte en secondes qui s'est écoulée depuis l'«époque Unix»[2]. Pas plus d'ailleurs que la date et heure UTC ne permettent non plus de calculer cette durée exacte.
Dans les deux cas, pour obtenir le décompte exact des secondes qui se sont écoulées depuis l'«epoch Unix», il faut se procurer une table des secondes intercalaires[3], et il faut ajouter à l'heure Posix la somme arithmétique des secondes intercalaires qui ont été insérées, ou bien retranchées, depuis cette «epoch Unix».
Pour l'heure UTC, cet écart est accepté car l'heure UTC est irrégulière par construction. Elle est asservie à la rotation de la Terre sur elle-même, qui elle-même est irrégulière. Depuis des millénaires, les habitudes de vie des hommes et des femmes sont rythmées, de façon universelle, par les cycles de rotation de la Terre sur elle-même. L'heure UTC est un outil créé pour, en quelques sortes, nous aider à rester synchronisés sur cette rotation.
Par contre, s'agissant de l'heure Unix ou heure Posix, c'est-à-dire un compteur de nombre de secondes écoulées depuis l'«époque Unix», il est dérangeant que ce décompte puisse être inexact. Cette convention de mesure du temps est dérangeante. Les paragraphes suivants de cet article donnent des éléments pour montrer comment s'en accommoder.
Le graphe de gauche montre la différence DUT1 entre UT1 et UTC. Les segments verticaux correspondent à l'insertion de secondes intercalaires.
Le graphe de droite montre les différences UT1-TAI, et UTC-TAI. Les marches d'escalier de la courbe UTC-TAI correspondent à l'insertion de secondes intercalaires.
Associer un événement dans le temps à un nombre réel
Pour associer un événement à un nombre réel, il suffit d'utiliser des références naturelles et universelles: par exemple, les périodicités de rotation de la Terre sur elle-même, et autour du Soleil. Ces périodicités sont suffisantes pour établir des calendriers, c'est-à-dire des relations entre des événements et des dates, même si quelques efforts sont nécessaires pour bien définir les références utilisées[4] (chaque pays a les siennes, toutes adoptées à des instants différents); les dates de ces calendriers ne sont que des nombres exprimés dans un système de numération un peu compliqué qui a pour unités le jour, la semaine, le mois, la saison, l'année, etc., et l'heure Posix n'est qu'une référence parmi d'autres exprimée sous forme d'un simple nombre.
Principaux systèmes de mesures utilisés
Voici les principaux systèmes de mesure du temps qui ont été imaginés et utilisés jusqu'à nos jours[5]:
Encore en usage dans certains pays pour des aspects légaux[7].
Néanmoins la définition de ce système de mesure est ambigüe[6]. C'est la raison pour laquelle, en dehors de cet usage administratif, il est préférable d'utiliser UTC.
Ce système définit le jour comme la durée moyenne de rotation de la Terre autour de son axe.
Cette définition pose quelques difficultés car la vitesse de cette rotation n’est pas constante, elle diminue lentement sous l’effet des marées et, de plus, présente des irrégularités imprévisibles: la durée des jours UT est très légèrement supérieure, en moyenne, à 86 400 secondes (nombre de secondes dans 24h). L'écart est de l’ordre de la seconde sur une à trois années.
On distingue plusieurs versions de UT: UT0, UT1, UT1R, UT2. On se reportera à l'article «Temps universel» pour plus de détails.
Ce système est fondé sur une définition internationale de la seconde. Son étalon est constitué par plusieurs horloges atomiques réparties dans le monde. La mesure du temps dans ce système est strictement régulière à la différence de la précédente pour qui son étalon n'a pas la même régularité. En conséquence, TAI et UT s'éloignent progressivement l'un de l'autre du fait du ralentissement du second; c'est ce que montre la figure ci-dessus.
Une différence de deux TAI permet de calculer un délai écoulé de façon exacte.
Ce système est adopté comme base du temps civil international par un grand nombre de pays. Le mot «coordonné» indique que:
la différence entre UTC et TAI est un nombre entier de secondes,
la différence entre UTC et UT1 n'est jamais plus grande que 0,9 seconde.
Autrement dit, UTC est identique au TAI (il en a la stabilité et l’exactitude) à un nombre entier de secondes près[8], et les secondes intercalaires lui permettent de coller à UT à 0,9 s près; c'est ce que montre la figure ci-dessus[9].
Une différence de deux heures UTC permet de calculer un délai écoulé de façon exacte tant que les deux événements ne sont pas à cheval sur une seconde intercalaire (voir ci-dessous la probabilité et l'amplitude de l'erreur). Pour calculer un délai exact en toutes circonstances, il faut tenir compte des secondes intercalaires[11].
Fermer
Choix d'une origine du temps
Pour mesurer le temps, il faut choisir une origine:
L'origine de l'heure POSIX a été choisie comme étant le 00:00:00 UTC[12], cette date correspond à l'heure 0 de Posix, elle est appelée l'epoch Posix (et également epoch Unix).
Évolution du temps
Il faut indiquer comment évolue ce nombre en fonction du temps qui passe:
Pour chaque seconde écoulée, l'heure POSIX s'accroît d'exactement une unité et ce de façon invariable tout au long de l'année, sauf lorsque l'IERS décide[10] d'ajouter (ou de supprimer) une seconde intercalaire; le tableau ci-dessous illustre le cas de l'ajout de la seconde intercalaire qui a eu lieu le à minuit[13].
Davantage d’informations #, TAI ...
Tableau 1: L'heure Posix au passage de minuit lorsqu'une seconde intercalaire fut ajoutée le à minuit
L'Heure Posix n'est pas une représentation linéaire du temps, il y a des anomalies[14], comme la ligne 5 du tableau ci-dessus.
Il n'y a pas correspondance bijective entre l'heure UTC et l'heure Posix; ce dernier ne permet pas de représenter les secondes intercalaires présentes dans UTC, comme la ligne 4 du tableau ci-dessus: 2008-12-31T23:59:60UTC.
Temps écoulé entre deux événements
Il ne faut pas mélanger ces différentes références (par exemple, l'an zéro d'un calendrier ne commence pas au même instant que celui d'un autre) et également parce que tous ces calendriers ont besoin de s'adapter aux périodicités non multiples les unes des autres, par exemple les années bissextiles, ou bien les irrégularités de ces périodicités. Ces adaptations compliquent un petit peu les calculs, en fonction de la précision que l'on recherche; par exemple, il s'est écoulé un an peut être une information suffisante ou bien il faudra tenir compte du caractère bissextile de l'année pour répondre à la même question exprimée en nombre de jours. Cela veut dire qu'il faut conserver une mémoire du passé, la mémoire de chaque seconde qui passe.
Dans la plupart des cas, une simple différence des heures Posix suffit, sauf si les deux événements sont à cheval sur une ou plusieurs secondes intercalaires. Pour calculer un délai exact en toutes circonstances, il faut tenir compte des secondes intercalaires.
Toutefois, l'occurrence des secondes intercalaires étant faible[15], la probabilité de commettre une telle erreur est donc faible; et si malgré tout le cas se produit, alors l'amplitude de l'erreur est peut-être faible[16], et il n'y a dans ce cas pas besoin de se préoccuper de ces secondes intercalaires; le tableau ci-dessous montre différents exemples.
La méthode pour compléter une ligne de ce tableau est la suivante:
si le délai calculé entre les deux événements d'intérêt est de l'ordre de M secondes, alors la probabilité qu'une seconde intercalaire soit dans cet intervalle est de M sur le nombre total N de secondes pendant une année (c'est-à-dire en prenant pour hypothèse qu'une seconde intercalaire est ajoutée chaque année),
une année compte N = 365 x 24 x 3 600 = 31 536 000 secondes,
la probabilité de commettre une erreur 1/M est donc de M/N = Mx3,2 × 10-8.
L'application de cette méthode pour des délais M=10, 100, 1000 donne le tableau suivant:
Davantage d’informations Délai à mesurer (M), Probabilité d'erreur ...
Tableau 2: Erreur commise et probabilité de commettre l'erreur
Délai à mesurer (M)
Probabilité d'erreur
Amplitude de l'erreur
10 s
3,2 × 10-7
10%
100 s
3,2 × 10-6
1%
1 000 s
3,2 × 10-5
0,1%
Fermer
À la limite, si le délai à calculer entre les deux événements d'intérêt est d'un an, alors la probabilité est de 100% de commettre une erreur de 3,2 × 10-8.
La probabilité de commettre une erreur donnée et l'amplitude de cette erreur varie inversement l'une de l'autre; une autre façon de présenter les choses pourrait être de dire:
si le délai calculé est petit, alors l'erreur peut être forte, mais la probabilité de la commettre est faible,
si le délai calculé est grand, alors la probabilité de commettre l'erreur est forte, mais l'erreur est faible.
Si ce couple (probabilité de commettre une erreur / amplitude de l'erreur) est inacceptable, ou bien si on ne sait pas en évaluer l'impact, alors il est sûrement nécessaire de se poser la question de savoir pourquoi on utilise UTC et quel est le besoin de précision nécessaire, ou bien de prévoir l'usage de tables à mettre à jour dès que l'insertion/retrait d'une seconde intercalaire est programmé[10],[17].
Conversion de l'heure UTC en heure Posix
Hormis les très rares anomalies mentionnées précédemment à propos des secondes intercalaires, il est aisé de convertir une heure UTC en une heure Posix et inversement.
Exemple: Quelle est l'heure Posix en tout début de la journée du (ligne 5 du tableau 1 ci-dessus):
de l'époque Posix au , 39 années se sont écoulées dont 10 bissextiles[18] (voir tableau d’aide ci-dessous),
soit 14 245 jours de 24x3 600=86 400 secondes chacun,
soit 1 230 768 000 secondes écoulées depuis l'époque Unix, hors secondes intercalaires. C'est l'heure Posix.
Davantage d’informations Nombre de jours écoulés, Nombre de secondes écoulées (hors secondes intercalaires) ...
Tableau 3: Calcul du nombre de secondes écoulées (hors secondes intercalaires) entre et , c'est l'heure Posix au
Nombre de jours écoulés
Nombre de secondes écoulées (hors secondes intercalaires)
Il existe des outils[19] qui réalisent ces calculs très simplement, comme ce «shell script» pour convertir une date en un nombre de secondes depuis l'époque Posix:
#!/bin/sh
# convertir une date (attention au format de l'argument)
# en nombre de secondes depuis l'époque Posix
#
# exemple: date --date "2009-01-01 00:00:00+00:00" "+heure POSIX = %s secondes"
#
# affiche: heure POSIX = 1230768000 secondes
#
date --date "$*" "+%s secondes"
Conversion d'une heure Posix en heure UTC
Le calcul inverse ne présente pas de difficulté, et de la même façon, il existe des outils[19] qui réalisent ces calculs très simplement, comme ce «shell script» pour convertir un nombre de secondes depuis l'époque Posix en une date:
#!/bin/sh
# convertir un nombre de secondes depuis l'époque Posix
# en date
#
# exemple: date -u --iso-8601=seconds --date "1970-01-01 1230768000 seconds"
#
# affiche: 2009-01-01T00:00:00+00:00
#
date -u -R --date "1970-01-01 $* seconds"
Nombre limité d'années qu'un système UNIX particulier peut représenter
La méthode plus courante pour lire l'heure sous Unix, est l'appel à la fonction suivante qui retourne une valeur numérique de type "time_t".
time_t time(NULL);
Ce type time_t est couramment utilisé pour manipuler l'heure UNIX, malheureusement la norme POSIX n'en précise pas (clairement) la taille:
Illustration du phénomène de débordement.si c'est une machine 32 bits, time_t sera vraisemblablement un entier signé 32 bits. Ce compteur permet de gérer une période totale de 232 secondes, soit à peu près 136 années. La date la plus reculée est , et la plus avancée est .
Lorsque cette date la plus avancée sera franchie, cette représentation va déborder(en), c'est-à-dire qu'elle ne sera plus capable de continuer à représenter l'heure Unix correctement. Ce problème est appelé le bug de l'an 2038. L'image animée ci-contre illustre le phénomène de débordement.
Davantage d’informations UTC ...
Heure Unix
UTC
date la plus reculée: -231
−2 147 483 648
1901-12-13 T 20:45:52
époque Unix : 0
0
1970-01-01 T 00:00:00
date la plus avancée: 231-1
2 147 483 647
2038-01-19 T 03:14:07
Fermer
si c'est une machine 64 bits, time t sera vraisemblablement un entier signé 64 bits; les limites seront alors supérieures à 292 milliards d'années soit beaucoup plus que l'âge de notre planète ou son espérance de vie.
Cette impossibilité de représentation ne met pas forcément en cause le fonctionnement de la machine elle-même, c'est-à-dire le fonctionnement de son système d'exploitation[20] mais le fonctionnement de ses applications et son interopérabilité avec les autres machines. En effet, il n'est pas suffisant qu'une machine sache localement gérer cette limite, mais il faut également que toutes les machines qui lui sont connectées[21] soient capables de gérer cette limite et ce de la même façon.
Plusieurs cas peuvent se présenter:
soit on a affaire à un parc de machines bien maitrisées, c'est le cas par exemple des systèmes embarqués. Dans ce cas, une solution pour gérer cette frontière peut être de s'assurer que le parc de machines n'utilise que des applications développées spécialement pour être robustes face à cette situation[22],[23],
soit on a affaire à un parc de machines très hétérogènes et non maitrisées, c'est le cas par exemple des machines du monde entier qui sont connectées sur internet. Dans ce cas, une solution serait de généraliser le codage de cette heure Unix sur 64 bits à toutes les machines, y compris celles en 32 bits. On peut également raisonnablement espérer que toutes les machines seront au moins 64 bits à l'aube de 2038.
Utilisation d'une résolution inférieure à la seconde
Les systèmes Unix entretiennent en général un compteur dont la résolution est plus fine que la seconde. Cette heure est accessible par un appel à la fonction suivante:
int gettimeofday(struct timeval *tv, NULL);
La valeur numérique retournée par cette fonction est mémorisée dans la variable «struct timeval *tv» définie de la façon suivante:
struct timeval {
int tv_sec; /* secondes */
int tv_usec; /* microsecondes de 0 à 999999 */
};
L'emploi de cette résolution inférieure à une seconde amène la question de savoir ce qui se passe lorsqu'une seconde intercalaire est ajoutée ou retranchée? Il semblerait que ce point soit à la charge du système d'exploitation[24]. En l'absence de spécification claire, plusieurs scénarios sont donc possibles en fonction du système d'exploitation considéré[25],[26],[27]. Les trois exemples ci-dessous exposent les trois catégories de cas qui semblent les plus représentatives, ils ne traitent que l'aspect insertion d'une seconde intercalaire mais ils pourraient facilement être adaptés au cas de la suppression:
l'horloge système peut être ajustée brutalement d'une seconde, ce qui donnera l'impression d'un retour en arrière[28].
Heure ajustée brutalement
Davantage d’informations #, UTC ...
#
UTC
tv_sec
tv_usec
4
2008-12-31T23:59:60.000
1 230 768 000
0
2008-12-31T23:59:60.500
1 230 768 000
500 000
5
2009-01-01T00:00:00.000
1 230 768 000
0
heure ajustée brutalement
2009-01-01T00:00:00.500
1 230 768 000
500 000
6
2009-01-01T00:00:01.000
1 230 768 001
0
Fermer
l'horloge système peut être maintenue constante pendant une seconde pendant l'insertion de la seconde intercalaire. Cela signifie que l'heure ne reviendra pas en arrière mais sera figée, en conséquence le possible impact sur les applications devrait être en principe moindre[28].
Heure figée
Davantage d’informations #, UTC ...
#
UTC
tv_sec
tv_usec
4
2008-12-31T23:59:60.000
1 230 768 000
0
2008-12-31T23:59:60.500
1 230 768 000
0
heure figée
5
2009-01-01T00:00:00.000
1 230 768 000
0
heure figée
2009-01-01T00:00:00.500
1 230 768 000
500 000
6
2009-01-01T00:00:01.000
1 230 768 001
0
Fermer
l'horloge système peut être ralentie pour compenser l'insertion de la seconde intercalaire[28].
Heure ralentie
Davantage d’informations #, UTC ...
#
UTC
tv_sec
tv_usec
4
2008-12-31T23:59:60.000
1 230 768 000
0
2008-12-31T23:59:60.500
1 230 768 000
250 000
heure ralentie
5
2009-01-01T00:00:00.000
1 230 768 000
500 000
heure ralentie
2009-01-01T00:00:00.500
1 230 768 000
750 000
heure ralentie
6
2009-01-01T00:00:01.000
1 230 768 001
0
Fermer
Utilisation du TAI
L'idée d'utiliser le temps atomique international a été proposée et défendue par de nombreuses personnes[29], mais ce n'est pas le sens qui a été donné par l'histoire, le choix retenu fut celui qui aujourd'hui est figé par la norme POSIX.
Daniel J. Bernstein a écrit des articles et logiciels[23] pour l'utilisation de TAI sur des systèmes de type UNIX. Son idée était de faire en sorte que les machines Unix entretiennent en interne une heure TAI, c'est-à-dire un nombre exact de secondes écoulées depuis une certaine epoch. C'est un compteur dont le fonctionnement n'est pas perturbé par l'insertion, ou suppression, de secondes intercalaires.
Ensuite pour afficher l'heure UTC courante, la machine doit utiliser une tables des secondes intercalaires en vigueur à l'instant du calcul. Cette table est mise à jour en local sur la machine, dès la parution des Bulletins de BIPM.
Pour gérer l'affichage des heures UTC ou bien n'importe quel fuseau horaire, il faut sélectionner une section appelée «right» de la base de données appelée «TZ_database»[30].
L'origine de l'heure TAI est définie de la façon suivante[31]:
Le 1er janvier 1972 00:00:00 UTC est le 1er janvier 1972 00:00:10 TAI.
Synchronisation des heures Unix et heure affichée par une machine Unix
Depuis le développement du protocole NTP Network Time Protocol, à l'exception de quelques cas particuliers, la très grande majorité des machines Unix sont aujourd'hui toutes synchronisées sur une même heure de référence.
Il devient alors légitime de se demander si l'heure affichée par une machine Unix est bien l'heure «exacte», ou bien si l'utilisateur doit, à sa charge, ajouter la somme arithmétiques des secondes intercalaires qui ont été insérées, ou retranchées, depuis l'epoch Unix. La réponse est simple, mais le mot «exact» peut être trompeur:
l'heure affichée avec la commande «date -u» est «l'heure UTC exacte»,
et dire que l'heure UTC affichée est exacte, revient aussi à dire que le nombre de secondes, calculées à partir de cette heure UTC, c'est-à-dire «l'heure Unix», est différent du nombre «exact» de secondes écoulées depuis l'epoch Unix. Ce n'est pas un nombre «exact» de secondes. Mais finalement, quelle importance …?
Une seconde catégorie de question revient régulièrement: «est ce que l'affichage d'une heure locale modifie l'heure Unix de la machine Unix?». La réponse est simple:
l'heure locale affichée est un décalage de l'affichage et non pas un décalage de l'heure Unix de la machine Unix.
$ (unset TZ ; echo -en 'Date et heure UTC\t: '; date --iso-8601=seconds --utc)
$ (export TZ='Europe/Paris' ; echo -en "Date et heure $TZ\t: "; date --iso-8601=seconds)
$ (export TZ='Canada/Eastern'; echo -en "Date et heure $TZ\t: "; date --iso-8601=seconds)
Date et heure UTC : 2023-09-01T09:04:46+00:00
Date et heure Europe/Paris : 2023-09-01T11:04:46+02:00
Date et heure Canada/Eastern: 2023-09-01T05:04:46-04:00
$ (unset TZ; date --utc '+%s'); (export TZ='Canada/Eastern'; date '+%s')
1693559793
1693559793
On pourra également consulter (en) Epoch time vs. time of day pour une discussion sur certains aspects légaux, et également les autres pages de ce site; en particulier (en) Plots of deltas between time scales pour comparer les écarts entre différentes références.
L’utilisation de l’ancienne appellation standard «temps moyen de Greenwich» (GMT, de l’anglais «Greenwich Mean Time») est désormais déconseillée parce que sa définition est ambiguë, au contraire d’UTC, qui doit lui être préférée. Ce sigle s’était imposé par la prépondérance de la marine britannique durant le XIXesiècle et fut plus tard rebaptisé Temps universel (UT, de l’anglais Universal Time). Comme le temps UTC est le temps civil du méridien origine des longitudes à Greenwich, certains ont tenté de prolonger l’usage de GMT en le traduisant désormais par «Greenwich Meridian Time» mais ce glissement sémantique n’a aucune valeur officielle.
Dans l’échelle UTC, les secondes et tous les autres sous-multiples (milliseconde, microseconde, etc.) sont de durée constante, mais la minute et toutes les unités supérieures (heure, jour, semaine, etc.) sont de durée variable. L’ajout ou la suppression de ces secondes intercalaires est rare, de l’ordre d'une seconde sur une à trois années. La plupart des jours UTC comportent 86 400 secondes, la plupart des heures 3 600 secondes, et la plupart des minutes 60 secondes mais certains peuvent comporter respectivement 86 401 s ou bien 86 399 s, 3 601 s ou bien 3 599 s et 61 s ou bien 59 s.
Si on traçait sur un graphique similaire la différence entre UT1 et TAI, on verrait UT1 et TAI s'éloigner progressivement l'un de l'autre au rythme du ralentissement de la rotation de la Terre; de même, on verrait UTC et TAI s'éloigner l'un de l'autre par bons successifs au rythme de l'ajout/suppression des secondes intercalaires.
Cet ajout (ou suppression) a lieu soit la fin de la dernière minute du dernier jour du mois précédant le 1erjuillet ou le 1erjanvier, exceptionnellement cela peut être le 1eravril ou le 1eroctobre, et est annoncé 6 mois à l'avance par l'IERS via son (en) BULLETIN C - Product metadata. En mars 2009, il n’y a jamais eu de suppression de secondes intercalaires, et vraisemblablement il n'y en aura jamais compte tenu du fait que la vitesse de rotation de la terre diminue inexorablement. Il pourra être intéressant de consulter les autres bulletins de l'IERS (en) IERS Bulletins.
Les secondes intercalaires futures sont prévues avec une anticipation de six mois au maximum, c'est le rythme à lequel l'IERS diffuse son bulletin de prévision. Pour les valeurs passées on peut faire usage d’une table.
Il y a une difficulté avec cette définition, dans le sens qu'UTC n'existait pas avant 1972; cette difficulté est contournée en utilisant des nombres négatifs pour une date antérieure à l'époque; ainsi 04-10-1957T00:00:00Z, 4 472 jours avant l'époque, est représenté par l'heure POSIX −4 472 × 86 400 = −386 380 800.
Un PC ne va pas spontanément ralentir/accélérer son compteur interne par lui-même; l'ajustement peut être fait par l'utilisateur ou bien plus vraisemblablement, s'il est connecté à internet, de façon automatique et quasi-silencieuse par un service d'horloge, généralement il s'agit de NTP.
Pour que cette dernière méthode soit utilisable à bord d'un système embarqué, cela nécessiterait la mise en œuvre d'une mise à jour automatique et en temps réel de la table.
Une années est bissextile si elle est multiple de 4, mais non multiple de 100 sauf si multiple de 400 (exemple, 2000 était bissextile). L’application de cette règle montre qu’il est suffisant de tester la divisibilité par 4 entre 1901 et 2099.
Il faut comprendre le mot connecté au sens large, cela concerne la connexion ethernet, mais également l'échange de fichiers via des disques amovibles pour lesquels la datation des fichiers est un point important, pour les sauvegardes par exemple.
Un article (en) Leap Second Handling by Operating Systems expose 3 cas possibles. Il est dit: «Linux kernels and most other Unix-like systems care about the leap seconds and handle them correctly.» mais sans réellement préciser ce que correctly signifie au juste.
Depuis 2008, les équipes Google ont développé un algorithme appelé «Leap Smear» dont le but est d'adoucir la transition addition ou retrait d'une seconde intercalaire. Voir (en) , «Google team encourage anyone smearing leap seconds to use a 24-hour linear smear from noon to noon UTC.»
Comme exemple pour évaluer l'impact de ces différents scénarios, on pourrait imaginer un instrument de mesure de vitesse qui mesure le délai écoulé pour une distance parcourue donnée: dans le 3e cas, la vitesse sera surestimée, au maximum dans un rapport 2, et dans les deux premiers cas d'un rapport qui pourra être infini. On se rappellera tout de même que la probabilité d'occurrence d'un tel phénomène est rarissime, voir plus haut
Sur les machines Unix cette base de données est sauvegardée dans le répertoire «/usr/share/zoneinfo/right/», alors que habituellement c'est la base «/usr/share/zoneinfo/posix/» qui est utilisée
