Heure Unix

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[2] (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.

Voici les principaux systèmes de mesure du temps qui ont été imaginés et utilisés jusqu'à nos jours[3] :

Pour mesurer le temps, il faut choisir une origine :

• L'origine de l'heure POSIX a été choisie comme étant le 1^er janvier 1970 00:00:00 UTC[10], cette date correspond à l'heure 0 de Posix, elle est appelée l'epoch Posix (et également epoch Unix).

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 d'une unité et ce de façon invariable tout au long de l'année, sauf lorsque l'IERS décide[8] 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[11].

L'Heure Posix n'est pas une représentation linéaire du temps, il y a des anomalies[12], 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:60 UTC.

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[13], 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[14], 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 :

À 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é[8] - [15].

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 1^er janvier 2009 (ligne 5 du tableau 1 ci-dessus) :

• de l'époque Posix au 1^er janvier 2009, 39 années se sont écoulées dont 10 bissextiles[16] (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.

Il existe également des outils[17] 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 -R --date "1970-01-01 1230768000 seconds"
        date -u -R --date "1970-01-01 $* seconds" 

Le calcul inverse ne présente pas de difficulté, et de la même façon il existe des outils[17] qui réalisent ces calculs très simplement, comme ce script bash 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" "+%s"
        date --date "$*" "+%s"

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 :

• 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 2³² secondes, soit à peu près 136 années. La date la plus reculée est 13 décembre 1901, et la plus avancée est 19 janvier 2038.

Illustration du phénomène de débordement.

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.

• 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[18] 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[19] soient capables de gérer cette limite et ce de la même façon.

Plusieurs cas peuvent se présenter :

1. 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[20] - [21],
2. 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.

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[22]. En l'absence de spécification claire, plusieurs scénarios sont donc possibles en fonction du système d'exploitation considéré[23] - [24]. 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[25].

Heure ajustée brutalement

• 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[25].

Heure figée

• l'horloge système peut être ralentie pour compenser l'insertion de la seconde intercalaire[25].

Heure ralentie

L'idée d'utiliser le temps atomique international a déjà été proposée et défendue par de nombreuses personnes[26], 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 également écrit des articles et logiciels[21] pour l'utilisation de TAI sur des systèmes de type UNIX.

La gigaseconde Unix désigne l'heure Unix 10⁹, qui représente le 9 septembre 2001.

• Seconde intercalaire
• Intercalation (mesure du temps)
• Network Time Protocol

• (en) History of IEEE P1003.1 POSIX time by Landon Curt Noll (en)
• (fr) Institut de Mécanique Céleste et de Calcul des Ephémérides (Observatoire de Paris - Bureau des longitudes - CNRS)
• (en) International Earth Rotation and Reference Systems Service (IERS)
• (en) The Future of Leap Seconds in UTC by Steve Allen

• (en) The Authorized Guide to Version 3 of the Single UNIX Specification (version librement accessible de IEEE Std 1003.1, 2004 Edition)