Heure Unix - Définition
La liste des auteurs de cet article est disponible ici.
Introduction
L'heure Posix (aussi appelée POSIX timestamp) est une mesure du temps utilisée principalement dans les systèmes qui respectent la norme POSIX, d'où son nom. Il s'agit du nombre de secondes écoulées depuis le 1er janvier 1970 00:00:00 UTC jusqu'à l'événement à dater, hors secondes intercalaires (voir ci-dessous). C'est la représentation POSIX du temps.
L'heure UNIX est rencontrée sur les systèmes de type UNIX qui respectent en général cette norme POSIX.
Heure POSIX
![](https://static.techno-science.net/illustration/Definitions/1200px/l/leapsecond.ut1-utc.svg_009a8b9f3f084e8c14b9d882a24a3c47.png")
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 (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 :
| Sigle | Signification | Définition |
|---|---|---|
| GMT | Temps Moyen de Greenwich | Encore en usage dans certains pays pour des aspects légaux. Néanmoins la définition de ce système de mesure est ambigüe. C'est la raison pour laquelle, en dehors de cet usage administratif, il est préférable d'utiliser UTC. |
| UT | Temps Universel | 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 augmente très lentement en moyenne (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. |
| TAI | Temps Atomique International | Ce système est basé 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'éloigne progressivement l'un de l'autre du fait du ralentissement du second.
|
| UTC | Temps Universel Coordonné | Ce système est adopté comme base du temps civil international par un grand nombre de pays. Le mot « coordonné » indique que :
Autrement dit, UTC est identique au TAI (il en a la stabilité et l’exactitude) à un nombre entier de secondes près, ce qui lui permet de coller à UT à 0,9 s près ; c'est ce que montre la figure ci-contre.
|
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 1er janvier 1970 00:00:00 UTC, 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'accroit d'exactement une unité et ce de façon invariable tout au long de l'année, sauf lorsque l'IERS décide 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 31 décembre 2008 à minuit.
| # | TAI | UTC | TAI - UTC | Heure Posix | |
|---|---|---|---|---|---|
| 1 | 2009-01-01T00:00:30 | 2008-12-31T23:59:57 | 33 | 1 230 767 997 | |
| 2 | 2009-01-01T00:00:31 | 2008-12-31T23:59:58 | 33 | 1 230 767 998 | |
| 3 | 2009-01-01T00:00:32 | 2008-12-31T23:59:59 | 33 | 1 230 767 999 | |
| 4 | 2009-01-01T00:00:33 | 2008-12-31T23:59:60 | 33 | 1 230 768 000 | ajout d'une seconde intercalaire |
| 5 | 2009-01-01T00:00:34 | 2009-01-01T00:00:00 | 34 | 1 230 768 000 | |
| 6 | 2009-01-01T00:00:35 | 2009-01-01T00:00:01 | 34 | 1 230 768 001 | |
| 7 | 2009-01-01T00:00:36 | 2009-01-01T00:00:02 | 34 | 1 230 768 002 |
L'Heure Posix n'est pas une représentation linéaire du temps, il y a des anomalies, comme par exemple 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 par exemple la ligne 4 du tableau ci-dessus : 2008-12-31T23:59:60 UTC.
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 est faible, 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, 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 :
| 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% |
À la limite, si le délai à calculer entre les 2 é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 faible, alors l'erreur peut être forte, mais la probabilité de la commettre est faible,
- si le délai calculé est fort, 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ée.
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 1er janvier 2010 :
- de l'époque Posix au 1er janvier 2010, 40 années se sont écoulées dont 10 bissextiles (voir tableau d’aide ci-dessous),
- soit 14 610 jours de 24x3 600=86 400 secondes chacun,
- soit 1 262 300 400 secondes écoulées depuis l'époque Unix, hors secondes intercalaires.
| Nombre de jours écoulés | ||||
|---|---|---|---|---|
| 1 970 | 1 971 | 1 972 | 1 973 | 3*365+366 = 1461 |
| 1 974 | 1 975 | 1 976 | 1 977 | 1461 |
| 1 978 | 1 979 | 1 980 | 1 981 | 1461 |
| 1 982 | 1 983 | 1 984 | 1 985 | 1461 |
| 1 986 | 1 987 | 1 988 | 1 989 | 1461 |
| 1 990 | 1 991 | 1 992 | 1 993 | 1461 |
| 1 994 | 1 995 | 1 996 | 1 997 | 1461 |
| 1 998 | 1 999 | 2 000 | 2 001 | 1461 |
| 2 002 | 2 003 | 2 004 | 2 005 | 1461 |
| 2 006 | 2 007 | 2 008 | 2 009 | 1461 |
| 14 610 | ||||
Il existe également des outils qui réalisent ces calculs très simplement, comme par exemple ce script bash pour convertir un nombre de secondes depuis l'époque Posix en une date :
#!/bin/bash # convertir un nombre de secondes depuis l'époque Posix # en date # exemple: date -u -R --date "1970-01-01 1230768000 seconds" date -u -R --date "1970-01-01 ${*} seconds" 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 qui réalisent ces calculs très simplement, comme par exemple ce script bash pour convertir une date en un nombre de secondes depuis l'époque Posix :
#!/bin/bash # 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" "+%s" date --date "${*}" "+%s"