La gestion de l'heure sous Linux

Le
Nicolas George
La gestion de l'heure sous Linux
==

Nicolas George, le 2008-04-10

(Toutes copies ou citations autorisés à condition d'indiquer la source.)


Deux fois par an, on voit débarquer sur les groupes de discussion consacrés
à l'utilisation de Linux des gens venus se plaindre de ce que leur
ordinateur n'est pas à l'heure. Il est toujours malaisé de leur expliquer
comment corriger le problème proprement, parce qu'il faut quelques
explications théoriques. Ces explications ne sont pas très compliquées. Les
voici.

« Il est midi moins cinq. Rendez-vous demain à 8 heures devant la
bibliothèque. » Cette phrase, tirée de la vie quotidienne, montre bien avec
quelle facilité nous manipulons les heures. Pourtant, l'heure est quelque
chose de plus compliqué. Imaginez que vous recevez un courrier électronique
d'un ami en séjour à New York, alors que vous-même êtes en France. Il vous
écrit « je te téléphonerai ce soir vers 19 h ». Mais à quelle heure va-t-il
vous appeler ? Quand il est 19 h en France, il est 13 h à New York, et quand
il est 19 h à New York, il est déjà une heure du matin en France.

Quand on programme ou configure un système informatique capable d'échanger
des messages avec le monde entier en une fraction de seconde, et de rester
en fonction pendant plusieurs mois, voire années, il faut tenir compte de
ces subtilités.

1. Heures locales
--

1.1. Un instant dans le temps

On sait depuis Einstein que « en même temps » ne veut rien dire : le temps
est une notion relative, il dépend du référentiel de l'observateur.
Cependant, dans la vie courante, les distances et les vitesses mises en jeu
sont trop faibles pour que ça fasse une quelconque différence.

Rappelons-nous les deux personnes qui se sont donné rendez-vous à 8 h devant
la bibliothèque. Disons que cette bibliothèque est à Paris. Un ami commun à
ces deux personnes, actuellement à Tokyo, regarde sa montre et y lit 15:00.
Il se dit alors « tiens, juste maintenant, mes deux amis doivent être en
train de se rencontrer devant la bibliothèque ». Il peut même décider de
leur téléphoner, pour vérifier.

On a donc un événement : l'instant où les deux amis se retrouvent dans la
bibliothèque, et deux manières de décrire quand a eu lieu cet événement :
« le 10 avril 2008, à 8 h, heure de Paris », et « le 10 avril 2008, à 15 h,
heure de Tokyo ». On pourrait aussi dire « 339435 heures après que Neil
Armstrong a posé le pied sur la Lune ». Ces trois phrases identifient toutes
le même instant dans le temps.


1.2. UTC

Le rythme de la vie est basé sur l'heure locale, l'heure légale : on va
bosser à 8 heures, on mange à midi, et à 21 h on commence à regarder une
connerie sur TF1.

Cependant, il est parfois nécessaire de calculer avec les heures, d'indiquer
précisément des instants. Combien s'est-il écoulé de temps entre le
25 décembre 2006, 17:30, heure de Paris, et le 21 juin 2007, 2:30, heure de
Moscou ? Difficile à dire : il faut connaître le décalage horaire, et
surtout son sens, il faut savoir si Moscou applique l'heure d'été ou pas, et
il faut ne pas se tromper dans le calcul.

Quand on est dans cette situation, on a recours à une heure normalisée, sans
lien avec la géographie ni avec les saisons.

L'heure qu'on utilise pour ça en général, c'est UTC, pour « Coordinated
Universal Time » (oui, l'ordre ne colle pas).

UTC, c'est une heure conventionnelle, sans décalage horaire, sans heure
d'été. Tous les jours durent 24 heures UTC, même si on voyage.

Ainsi, « le 10 avril 2008, à 8 h, heure de Paris » peut se dire « « le
10 avril 2008, à 6 h UTC », Neil Armstrong a marché sur la Lune le
21 juillet 1969 à 3 h UTC (moins quatre minutes, j'ai arrondi). Le
25 décembre 2006, 17:30, heure de Paris correspond à au 25 décembre 2006,
16:30 UTC, et le 21 juin 2007, 2:30, heure de Moscou correspond au 20 juin
2007, 22:30 UTC. Notons que dans ce dernier cas, la date a changé à cause du
décalage entre l'heure de Moscou et l'heure UTC. Ces deux dernières
conversions permettent de faire le calcul : il s'est écoulé 4254 heures
entre les deux dates citées.

UTC coïncide avec l'heure de Londres en hiver.

D'ailleurs, naguère on disait « GMT » (pour « Greenwich Mean Time »,
Greenwich étant un quartier de Londres où se trouve un observatoire). On
retrouve encore GMT à certains endroits, mais il vaut mieux éviter cette
appellation, car elle porte quelques ambiguïtés.


1.3. TAI et les secondes intercalaires

L'heure locale, on a envie qu'elle colle assez bien avec le passage du
Soleil dans le ciel.

D'autre part, on a envie que la conversion en UTC et heure locale soit
simple : si possible, un nombre entier et constant d'heures.

Hélas, la Terre n'est pas accommodante, elle s'obstine à tourner
irrégulièrement. Pour compenser cette irrégularité, les autorités
compétentes décident de temps en temps l'ajout d'une seconde supplémentaire,
appelée seconde intercalaire. Quand ça arrive, il y a un jour où, tout à
fait officiellement, entre 23:59:59 UTC et 00:00:00 UTC le jour suivant, il
y a un 23:59:60.

Il existe une autre heure de référence, TAI (pour « Temps Atomique
International »), qui est plus exacte qu'UTC puisque les secondes
intercalaires ne sont pas insérées. La conversion entre UTC et TAI se fait
en ajoutant ou retranchant un nombre de secondes qui varie à chaque seconde
intercalaire. À l'instant où j'écris ces lignes, ce nombre est 23 : le
10 avril 2008, 12:00:00 TAI correspond au 10 avril 2008, 12:00:23 UTC.

En pratique, tout le monde se fiche des secondes intercalaires, et la
plupart des applications, même relativement précises, se contentent
d'ignorer le problème : de toutes façons, les horloges de la vie courante ne
sont pas assez précises pour voir la différence.


1.4. Lire une heure

Quand une heure est écrite par un outil sérieux et soucieux des problèmes
évoqués ici, cette heure précise la zone horaire à laquelle il est fait
référence. Par exemple, j'ai à chaque fois précisé « heure de Moscou »,
« heure de Tokyo », « UTC ».

Cette notation peut prendre différentes formes conventionnelles, plus
compactes que de tout écrire.

Dans le cas d'UTC, on peut simplement écrire « UTC », c'est simple.

Pour les heures locales de différents pays, il existe des sigles
conventionnels.

Pour les Français et leurs voisins, les sigles à connaître sont « CET »,
pour « Central European Time », et « CEST » (le S pour « Summer »), qui
désignent l'heure locale des pays d'Europe de l'ouest (sauf l'Angleterre)
respectivement en hiver et en été. On trouve parfois, sur certains systèmes
mal mis à jour, « MET » et « MEST » pour dire à peu près la même chose.

Cette notation a le défaut qu'elle exige que la signification des sigles
soit connue. Il existe également une notation avec des chiffres. On écrit ça
sous la forme d'un signe (+ ou -), de deux chiffres pour les heures, et deux
chiffres pour les minutes, qui indique le décalage par rapport à UTC.

Par exemple, avec « +0200 », on désigne une heure en avance de deux heures
sur UTC (l'heure d'été de l'Europe de l'ouest, par exemple), et avec
« -0430 », on désigne une heure qui retarde de quatre heure et demie sur UTC
(l'heure du Vénézuela jusqu'à il y a une cinquantaine d'années, par
exemple). Les décalages qui ne sont pas un nombre entier d'heures tendent à
être abandonnés.

Il y a donc des correspondances :

- CET est synonyme de +0100
- CEST est synonyme de +0200
- EST est synonyme de -0500
- EDT est synonyme de -0400



2. Comment un Unix gère l'heure
-

2.1. L'heure système

Sous Unix, qui sert de modèle à Linux, le choix qui a été fait pour stocker
et tenir à jour l'heure de référence du système est de compter un nombre de
secondes à partir d'une référence conventionnelle. Ce système a le mérite de
la simplicité : toutes les conversions en heures, minutes, secondes, avec
les divisions par 60 et les modulo dans tous les sens sont gardées pour plus
tard.

L'instant de référence est le premier janvier 1970 à 0:00 UTC.

Ce choix de représentation est probablement le plus simple, car autant les
nombres sont gros (on a largement dépassé le milliard) et peu parlant pour
des humains, autant ils sont simples à manipuler pour des ordinateurs.

On peut signaler que, sur les systèmes 32 bits, ce nombre est en général
stocké comme un entier signé 32 bits, ce qui place la limite à 2147483647,
soit le 19 janvier 2038 à 4:14:07 CET. Les systèmes 64 bits survivront
beaucoup plus loin.


2.2. L'affichage de l'heure

Évidemment, ce nombre n'est pas présenté tel quel à l'utilisateur. Mais la
conversion est faite au dernier moment, juste avant l'affichage.

La conversion d'un instant Unix en une heure UTC est assez simple, c'est de
l'arithmétique facile. Extraire la date est nettement plus pénible (il faut
gérer la durée des mois, et les années bissextiles). Gérer l'heure locale
demande d'avoir les caractéristiques exactes de l'heure locale, ce qui est
pénible.

Cette conversion pénible est écrite une fois pour toutes dans la
bibliothèque standard du système (la « libc »), sous la forme de la fonction
localtime. La conversion inverse existe également.

Les données de la conversion sont obtenues de trois manières différentes :

- La variable d'environnement TZ peut contenir les caractéristiques
complètes du calcul. Par exemple, sauf erreur de ma part,
« TZÎT-1CEST,M3.5.0/2,M10.5.0/3 » définit l'heure locale française,
avec l'heure d'été (il y a une notation particulière pour « le dernier
dimanche du mois »).

Cette notation est rarement utilisée, parce que les autres sont plus
simples.

- La variable d'environnement TZ peut également contenir le nom d'une zone
horaire. La libc va alors chercher dans /usr/share/zoneinfo/ le fichier
correspondant, qui contient toutes les caractéristiques nécessaires.

- Enfin, si la variable d'environnement TZ n'est pas positionnée, c'est le
fichier /etc/localtime qui est consulté. Ce fichier est normalement une
copie d'un des fichiers de /usr/share/zoneinfo/.


2.3. Le réglage de l'heure au boot

Quand Linux démarre, il a besoin de faire le réglage initial de son horloge
système. Sur un ordinateur de type PC ou proche, c'est en générale l'horloge
CMOS qui sert à cet usage, car elle reste alimentée même quand le PC est
éteint.

Évidemment, cette horloge stocke l'heure sous la forme heures, minutes,
secondes, et évidemment, sans indication de zone horaire. Il y a bien un bit
pour savoir si c'est une heure d'été ou d'hiver, mais personne ne s'en sert
correctement.

Donc au boot du système, un script appelle la commande idoine (hwclock), qui
va interroger l'horloge CMOS, faire la conversion de la zone horaire
supposée de cette horloge vers un temps Unix, et régler l'heure système en
conséquence. À l'extinction, éventuellement, l'opération inverse est faite.

Pour que ça marche, il faut savoir dans quelle zone horaire est réglée
l'horloge CMOS. Cette information est présente dans les scripts de
démarrage. Le plus fiable est que cette zone horaire soit UTC, car ça ne
pose pas de problèmes d'heure d'été (si le PC est éteint à ce moment-là,
l'horloge CMOS ne peut pas automatiquement passer en heure d'été). Hélas,
certains systèmes ne sont pas capables de gérer ça : si la compatibilité
avec ces systèmes est requise, cette solution n'est pas applicable.


2.4. NTP

NTP veut dire Network Time Protocol. C'est un système pour maintenir en
permanence à l'heure un ordinateur, pour peu qu'il soit doté d'une connexion
réseau. Un ordinateur relié au réseau, avec un démon NTP qui tourne et
interroge des serveurs corrects sera toujours correctement à l'heure.


3. Comment diagnostiquer et débugger les problèmes d'heure
-

3.1. Régler correctement la zone horaire

La première chose à faire, c'est de vérifier si la zone horaire est
correctement réglée. Pour ça, on peut utiliser la commande date. On obtient
une sortie de ce genre :

ssecem ~ $ date
Thu Apr 10 15:18:22 CEST 2008

C'est le « CEST » qu'il faut remarquer ; l'heure elle-même n'a pas
d'importance pour le moment. Si le système est réglé en français, on aura :

ssecem ~ $ date
jeudi 10 avril 2008, 15:18:52 (UTC+0200)

On peut retrouver le sigle avec :

ssecem ~ $ LC_ALL=C date
Thu Apr 10 15:19:46 CEST 2008

L'étape suivante consiste à se renseigner pour vérifier que la zone horaire
affichée est bien celle qui correspond à là où on vit. On peut par exemple
chercher « CEST » sur Wikipedia.

Si on constate un problème, il faut encore déterminer d'où vient le
problème : la configuration de l'heure globale, ou une configuration
personnelle. On recommence donc les opérations après avoir tapé :

ssecem ~ $ unset TZ

Si ça ne colle pas, il faut réparer. Le plus simple est de choisir une zone
horaire nommée en fonction de la ville de référence. Par exemple, pour la
France métropolitaine, la zone horaire est « Europe/Paris ». La liste
complète peut être obtenue en regardant les fichiers présents dans
/usr/share/zoneinfo/.

Il reste maintenant à faire le réglage. Pour régler l'heure pour l'ensemble
du système, c'est /etc/localtime qu'il faut modifier. Normalement, les
distributions ont quelque chose pour le faire confortablement, il vaut mieux
l'utiliser (faute de quoi le changement sautera à la prochaine mise à jour).

Par exemple, sur Debian, la zone se règle avec :

ssecem ~ $ sudo dpkg-reconfigure tzdata

(le réglage lui-même étant stocké dans /etc/timezone).

Si la distribution n'a aucun outil, on peut se contenter de copier le
fichier :

ssecem ~ $ sudo cp /usr/share/zoneinfo/Europe/Paris /etc/localtime

Si on veut régler pour soi seul (quand on n'est qu'un utilisateur parmi
d'autres, qui vivent ailleurs), il suffit de mettre :

TZ=Europe/Paris
export TZ

dans un des scripts d'ouverture de session (je choisis .zshenv,
personnellement).


3.2. Régler l'heure tout de suite

Maintenant que la zone horaire est correcte, il est utile de régler tout de
suite, manuellement, l'heure système. Pour ça, on utilise la commande date :

ssecem ~ $ sudo date -s '2008-04-10 15:42:00 CEST'

(après avoir appelé l'horloge parlante ; il peut être intéressant d'avoir
tapé « sudo true » juste avant pour que sudo ne demande pas le mot de
passe).

Si on a une connexion réseau, on peut également utiliser NTP :

ssecem ~ $ sudo ntpdate -ub pool.ntp.org

On vérifie ensuite avec « date » que l'heure a correctement été fixée, y
compris la zone horaire.


3.3. Régler correctement l'horloge CMOS

Pour que le réglage persiste après le reboot, il faut régler l'horloge CMOS.

Pour ça, il faut commencer par décider si l'horloge CMOS est en heure locale
ou en heure UTC. Le meilleur choix est UTC, car il ne demande absolument
aucune maintenance ultérieure. Hélas, certains systèmes autres que Linux ne
supportent pas ce choix. Si vous utilisez ces systèmes, vous devez choisir
l'heure locale.

L'outil qui synchronise horloge CMOS et horloge système s'appelle hwclock.
La différence se fait par le passage de l'option --utc (ou -u) ou
--localtime. Si aucune des deux n'est passée, hwclock choisit selon une
valeur stockée dans un fichier quelque part. Donc passez toujours l'option à
hwclock explicitement, c'est plus fiable.

Le choix de la convention au boot relève encore une fois de la distribution.
On peut aller fouiller dans les scripts de boot pour trouver où hwclock est
appelé, et quelles options sont utilisées. Sous Debian, par exemple, c'est
dans le fichier /etc/init.d/hwclockfirst.sh, et on y lit que l'appel à
hwclock dépend de la variable UTC définie dans /etc/default/rcS.

Une fois qu'on s'est assuré que les scripts de boot étaient réglés sur la
convention choisie, on va stocker l'heure système dans l'horloge CMOS (cette
opération est normalement faite à l'extinction du système, mais parfois
c'est désactivé, et ça n'arrive pas en cas de coupure de courant) :

ssecem ~ $ sudo hwclock --utc --systohc

Normalement, quand on en est arrivé là, on peut rebooter, et l'heure sera
correcte.

Attention : avec les systèmes de suspend-to-disk et d'hibernation des
portables modernes, le réglage de l'heure à la sortie de l'hibernation n'est
pas géré exactement pareil. C'est à nouveau l'horloge CMOS qui entre en jeu,
mais je ne sais pas où on indique qu'elle est en UTC ou en heure locale.


3.4. Utiliser NTP

Les composants qui suivent l'heure sur un PC ne sont pas extrêmement précis.
Pour éviter d'avoir à re-régler l'heure trop souvent, il vaut mieux, autant
que possible, utiliser NTP.

Attention cependant : ÇA NE DISPENSE PAS DE RÉGLER CORRECTEMENT LA ZONE
HORAIRE ET L'HORLOGE CMOS. Il est important que l'heure soit correctement
réglée même si le réseau est en rade quand l'ordinateur boote.

Si on dispose d'une connexion réseau permanente, le plus simple est
d'installer et lancer ntpd. En général, il vient configuré pour interroger
différents serveurs ouverts dans le monde. On peut ajouter à sa
configuration (/etc/ntp.conf) des serveurs plus proches si on en connaît
(les FAI ou les grosses institutions en ont souvent).

À noter que ntpd est à la fois client et serveur : si vous avez plusieurs
ordinateurs à la maison, vous pouvez faire en sorte qu'ils interrogent tous
le plus fiable d'entre eux en NTP.

On peut regarder l'état de NTP avec la commande suivante :

ssecem ~ $ ntpq -p

Si on ne dispose que d'une connexion réseau transitoire, on peut régler les
choses pour qu'un réglage NTP soit fait automatiquement à l'établissement de
la connexion. Par exemple, on peut mettre un appel à ntpdate dans un script
sous /etc/ppp/ip-up.d/.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Jacques Gerbaud
Le #2740711
La gestion de l'heure sous Linux
=============================== >
Nicolas George, le 2008-04-10

(Toutes copies ou citations autorisés à condition d'indiquer la source.)


Deux fois par an, on voit débarquer sur les groupes de discussion consacrés
à l'utilisation de Linux des gens venus se plaindre de ce que leur
ordinateur n'est pas à l'heure. Il est toujours malaisé de leur expliquer
comment corriger le problème proprement, parce qu'il faut quelques
explications théoriques. Ces explications ne sont pas très compliquées. Les
voici.
...........snip


Bravo Nicolas.

Un tutoriel bien fait qui nous explique pas mal de choses.

Je suis assez souvent confronté au coup du décalage horaire concernant
l'heure locale (pour le RDV à la bibliothèque) pour les (futurs appels
téléphoniques de ma fille qui se trouve à New Delhi) et on prend bien garde,
à chaque fois de préciser de quelle heure locale il s'agit : la sienne ou la
mienne !

Enfin, on a bien compris qu'un ordinateur est assemblé quelque part et que
son utilisation pourra être n'importe où dans le monde et qu'il faut,
effectivement avoir des règles pour organiser tout ça !

Tu devrais contacter les "maîtres" des diverses distributions pour qu'il
mettent le présent tutoriel dans leur "doc".

Cordialement

--
Jean-Jacques Gerbaud
Entre Dauphiné et PACA (France)

Fabien LE LEZ
Le #2740701
On 10 Apr 2008 14:09:48 GMT, Nicolas George :
2.4. NTP


Est-il envisageable de se passer purement et simplement de l'heure
CMOS, et de se contenter de NTP ?

Nicolas George
Le #2740691
Fabien LE LEZ wrote in message
Est-il envisageable de se passer purement et simplement de l'heure
CMOS, et de se contenter de NTP ?


Bof. Le réseau ou le serveur NTP peut être en rade au moment du boot
(typiquement en cas de panne de courant affectant toutes les machines d'un
même établissement), et pour un certain temps ensuite. C'est quand même
dommage si l'heure est dans les choux dans ces cas-là.

Et surtout : quel intérêt ?

Jacques Lav!gnotte - Drop Dr NO when replying
Le #2757831
On 10 Apr 2008 14:09:48 GMT, Nicolas George :
2.4. NTP


Est-il envisageable de se passer purement et simplement de l'heure
CMOS, et de se contenter de NTP ?


Sur le serveur je récupère l'heure par NTP et l'applique à la CMOS.

man hwclock

Jacques


Fabien LE LEZ
Le #2767031
On 10 Apr 2008 21:49:07 GMT, Nicolas George :

Est-il envisageable de se passer purement et simplement de l'heure
CMOS, et de se contenter de NTP ?


Et surtout : quel intérêt ?


Je pourrais retourner la question : quel intérêt de se préoccuper de
ce que dit une horloge imprécise, quand on a mieux à sa disposition ?


Eric Razny
Le #2769331
Le Fri, 11 Apr 2008 04:06:27 +0200, Fabien LE LEZ a écrit :

Est-il envisageable de se passer purement et simplement de l'heure
CMOS, et de se contenter de NTP ?


Et surtout : quel intérêt ?


Je pourrais retourner la question : quel intérêt de se préoccuper de ce
que dit une horloge imprécise, quand on a mieux à sa disposition ?


Salut

S'il y a une trop grosse différence entre l'heure "actuelle" et l'heure
réelle, ntpd ne fera pas une mise à jour brutale, et ta machine va être
aux fraises, niveau temps, pour des heures.

On suppose un accès au net déficiant au démarrage, donc même un
ntpdate ne te sauvera pas la mise.

Donc mieux vaut un truc pas hyper précis que rien, non? :)

Eric



Bernard
Le #2875311
Le Thu, 10 Apr 2008 23:27:02 +0200, Jean-Jacques Gerbaud a écrit :

La gestion de l'heure sous Linux
=============================== >>
Nicolas George, le 2008-04-10

(Toutes copies ou citations autorisés à condition d'indiquer la
source.)


Deux fois par an, on voit débarquer sur les groupes de discussion
consacrés à l'utilisation de Linux des gens venus se plaindre de ce
que leur ordinateur n'est pas à l'heure. Il est toujours malaisé de
leur expliquer comment corriger le problème proprement, parce qu'il
faut quelques explications théoriques. Ces explications ne sont pas
très compliquées. Les voici.
...........snip


Bravo Nicolas.

Un tutoriel bien fait qui nous explique pas mal de choses.




Oui, merci à tous les contributeurs, et félicitations à Nicolas pour
son texte fort instructif.


G-raison
Le #4451001
et à 21 h on commence à regarder une
connerie sur TF1.


:-)

--
@+
gr

Publicité
Poster une réponse
Anonyme