Heure Unix - Définition
La liste des auteurs de cet article est disponible ici.
Heure UNIX
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 :
- 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 13 décembre 1901, et la plus avancée est 19 janvier 2038.
- 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.
Illustration du phénomène de débordement.
| 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 |
- si c'est une machine 64 bits, time t sera vraisemblablement un entier signé 64 bits ; les limites seront alors supérieures à l'âge de notre planète et à 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 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 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,
- 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 à 999 999 */ }; L'emploi de cette résolution inférieure à une seconde amène la question de savoir ce qui se passe lorsque une seconde intercalaire est ajoutée ou retranchée ? Il semblerait que ce point soit à la charge du système d'exploitation. En l'absence de spécification claire, plusieurs scénarios sont donc possibles en fonction du système d'exploitation considéré. 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.
| # | 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 |
- 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.
| # | 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 |
- l'horloge système peut être ralentie pour compenser l'insertion de la seconde intercalaire.
| # | 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 |
Utilisation du TAI
L'idée d'utiliser le Temps atomique international a déjà été proposée et défendue par de nombreuses personnes, 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 pour l'utilisation de TAI sur des systèmes de type UNIX.
