Je viens de remarquer que mon serveur dédié OVH avait 1h de moins que
la "bonne" heure. Je l'ai reréglé via Plesk en l'associant au fuseau
horaire GMT+2 (Paris) et en le synchronisant avec un serveur de temps.
Désormais, tant PHP que la commande 'date' sous SSH me donnent la bonne
heure.
Ma question toute bête : comment être certain qu'il s'ajustera tout
seul à l'heure d'hiver le moment venu ?
En fouillant sur Google, j'ai trouvé une page conseillant d'ajouter
dans /etc/rc.d/rc.local la commande clock -u -s
Quelqu'un peut il me confirmer ça ?
Un grand merci d'avance à ceux qui savent :)
Olivier
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
O.L. wrote in message :
Ma question toute bête : comment être certain qu'il s'ajustera tout seul à l'heure d'hiver le moment venu ?
Sous Unix, l'heure est comptée uniquement en secondes (non-intercalaires) depuis l'instant de référence du 1970-01-01T00:00:00+0000. La conversion n'est faite qu'au moment où on veut afficher l'heure locale. Dans ces conditions, il n'y a pas d'ajustement qui intervienne : il n'y a rien à changer au moment du changement d'heure, c'est juste la conversion qui donnera un résultat différent.
Comment s'assurer que tout fonctionne bien :
- Vérifier que /etc/localtime est bien identique au fichier de /usr/share/zoneinfo qui convient.
- Si on a un réseau permanent, lancer ntpd pour assurer une synchronisation en continue avec les serveurs de temps.
- Dans les scripts d'allumage et d'extinction, mettre le nécessaire pour synchroniser l'horloge CMOS avec l'horloge système. C'est la commande hwclock qui sert à ça. Normalement, les distributions prévoient tout le nécessaire, il n'y a rien à toucher.
Le dernier point est important : l'horloge CMOS stocke une heure, pas un instant Unix. Pour que le problème de changement d'heure ne se pose pas, il convient que ce réglage soit fait UTC, qui n'a pas de changement d'heure. Hélas, certains systèmes d'exploitations conçus par des abrutis ne sont pas capables de se synchroniser avec une horloge CMOS en UTC.
O.L. wrote in message <mn.83cc7d79ab715786.68583@undefined.invalid>:
Ma question toute bête : comment être certain qu'il s'ajustera tout
seul à l'heure d'hiver le moment venu ?
Sous Unix, l'heure est comptée uniquement en secondes (non-intercalaires)
depuis l'instant de référence du 1970-01-01T00:00:00+0000. La conversion
n'est faite qu'au moment où on veut afficher l'heure locale. Dans ces
conditions, il n'y a pas d'ajustement qui intervienne : il n'y a rien à
changer au moment du changement d'heure, c'est juste la conversion qui
donnera un résultat différent.
Comment s'assurer que tout fonctionne bien :
- Vérifier que /etc/localtime est bien identique au fichier de
/usr/share/zoneinfo qui convient.
- Si on a un réseau permanent, lancer ntpd pour assurer une synchronisation
en continue avec les serveurs de temps.
- Dans les scripts d'allumage et d'extinction, mettre le nécessaire pour
synchroniser l'horloge CMOS avec l'horloge système. C'est la commande
hwclock qui sert à ça. Normalement, les distributions prévoient tout le
nécessaire, il n'y a rien à toucher.
Le dernier point est important : l'horloge CMOS stocke une heure, pas un
instant Unix. Pour que le problème de changement d'heure ne se pose pas, il
convient que ce réglage soit fait UTC, qui n'a pas de changement d'heure.
Hélas, certains systèmes d'exploitations conçus par des abrutis ne sont pas
capables de se synchroniser avec une horloge CMOS en UTC.
Ma question toute bête : comment être certain qu'il s'ajustera tout seul à l'heure d'hiver le moment venu ?
Sous Unix, l'heure est comptée uniquement en secondes (non-intercalaires) depuis l'instant de référence du 1970-01-01T00:00:00+0000. La conversion n'est faite qu'au moment où on veut afficher l'heure locale. Dans ces conditions, il n'y a pas d'ajustement qui intervienne : il n'y a rien à changer au moment du changement d'heure, c'est juste la conversion qui donnera un résultat différent.
Comment s'assurer que tout fonctionne bien :
- Vérifier que /etc/localtime est bien identique au fichier de /usr/share/zoneinfo qui convient.
- Si on a un réseau permanent, lancer ntpd pour assurer une synchronisation en continue avec les serveurs de temps.
- Dans les scripts d'allumage et d'extinction, mettre le nécessaire pour synchroniser l'horloge CMOS avec l'horloge système. C'est la commande hwclock qui sert à ça. Normalement, les distributions prévoient tout le nécessaire, il n'y a rien à toucher.
Le dernier point est important : l'horloge CMOS stocke une heure, pas un instant Unix. Pour que le problème de changement d'heure ne se pose pas, il convient que ce réglage soit fait UTC, qui n'a pas de changement d'heure. Hélas, certains systèmes d'exploitations conçus par des abrutis ne sont pas capables de se synchroniser avec une horloge CMOS en UTC.
O.L.
Nicolas George a pensé très fort :
O.L. wrote in message :
Ma question toute bête : comment être certain qu'il s'ajustera tout seul à l'heure d'hiver le moment venu ?
Sous Unix, l'heure est comptée uniquement en secondes (non-intercalaires) depuis l'instant de référence du 1970-01-01T00:00:00+0000. La conversion n'est faite qu'au moment où on veut afficher l'heure locale. Dans ces conditions, il n'y a pas d'ajustement qui intervienne : il n'y a rien à changer au moment du changement d'heure, c'est juste la conversion qui donnera un résultat différent.
Comment s'assurer que tout fonctionne bien :
- Vérifier que /etc/localtime est bien identique au fichier de /usr/share/zoneinfo qui convient.
Donc je pense que là c'est bon (suite à l'ajustement via Plesk)
- Si on a un réseau permanent, lancer ntpd pour assurer une synchronisation en continue avec les serveurs de temps.
OK, ça Plesk s'en charge je pense.
- Dans les scripts d'allumage et d'extinction, mettre le nécessaire pour synchroniser l'horloge CMOS avec l'horloge système. C'est la commande hwclock qui sert à ça. Normalement, les distributions prévoient tout le nécessaire, il n'y a rien à toucher.
Le dernier point est important : l'horloge CMOS stocke une heure, pas un instant Unix. Pour que le problème de changement d'heure ne se pose pas, il convient que ce réglage soit fait UTC, qui n'a pas de changement d'heure. Hélas, certains systèmes d'exploitations conçus par des abrutis ne sont pas capables de se synchroniser avec une horloge CMOS en UTC.
[ ~]# hwclock --show dim 16 sep 2007 16:50:50 CEST -0.383127 secondes
Je vois "CEST" et pas "UTC", c'est donc qu'il y a un problème ? :-/
Il faut peut être aussi poser la question suivante : savez vous comment faire pour que PHP (c'est un serveur web qui n'utilise pratiquement que ce langage) fasse bien l'ajustement heure été/hiver lorsque l'on lui demande le résultat de la fonction date() ? Y a t'il une option à vérifier dans le php.ini ?
O.L. wrote in message <mn.83cc7d79ab715786.68583@undefined.invalid>:
Ma question toute bête : comment être certain qu'il s'ajustera tout
seul à l'heure d'hiver le moment venu ?
Sous Unix, l'heure est comptée uniquement en secondes (non-intercalaires)
depuis l'instant de référence du 1970-01-01T00:00:00+0000. La conversion
n'est faite qu'au moment où on veut afficher l'heure locale. Dans ces
conditions, il n'y a pas d'ajustement qui intervienne : il n'y a rien à
changer au moment du changement d'heure, c'est juste la conversion qui
donnera un résultat différent.
Comment s'assurer que tout fonctionne bien :
- Vérifier que /etc/localtime est bien identique au fichier de
/usr/share/zoneinfo qui convient.
Donc je pense que là c'est bon (suite à l'ajustement via Plesk)
- Si on a un réseau permanent, lancer ntpd pour assurer une synchronisation
en continue avec les serveurs de temps.
OK, ça Plesk s'en charge je pense.
- Dans les scripts d'allumage et d'extinction, mettre le nécessaire pour
synchroniser l'horloge CMOS avec l'horloge système. C'est la commande
hwclock qui sert à ça. Normalement, les distributions prévoient tout le
nécessaire, il n'y a rien à toucher.
Le dernier point est important : l'horloge CMOS stocke une heure, pas un
instant Unix. Pour que le problème de changement d'heure ne se pose pas, il
convient que ce réglage soit fait UTC, qui n'a pas de changement d'heure.
Hélas, certains systèmes d'exploitations conçus par des abrutis ne sont pas
capables de se synchroniser avec une horloge CMOS en UTC.
[root@nsxxxx ~]# hwclock --show
dim 16 sep 2007 16:50:50 CEST -0.383127 secondes
Je vois "CEST" et pas "UTC", c'est donc qu'il y a un problème ? :-/
Il faut peut être aussi poser la question suivante : savez vous comment
faire pour que PHP (c'est un serveur web qui n'utilise pratiquement que
ce langage) fasse bien l'ajustement heure été/hiver lorsque l'on lui
demande le résultat de la fonction date() ?
Y a t'il une option à vérifier dans le php.ini ?
Ma question toute bête : comment être certain qu'il s'ajustera tout seul à l'heure d'hiver le moment venu ?
Sous Unix, l'heure est comptée uniquement en secondes (non-intercalaires) depuis l'instant de référence du 1970-01-01T00:00:00+0000. La conversion n'est faite qu'au moment où on veut afficher l'heure locale. Dans ces conditions, il n'y a pas d'ajustement qui intervienne : il n'y a rien à changer au moment du changement d'heure, c'est juste la conversion qui donnera un résultat différent.
Comment s'assurer que tout fonctionne bien :
- Vérifier que /etc/localtime est bien identique au fichier de /usr/share/zoneinfo qui convient.
Donc je pense que là c'est bon (suite à l'ajustement via Plesk)
- Si on a un réseau permanent, lancer ntpd pour assurer une synchronisation en continue avec les serveurs de temps.
OK, ça Plesk s'en charge je pense.
- Dans les scripts d'allumage et d'extinction, mettre le nécessaire pour synchroniser l'horloge CMOS avec l'horloge système. C'est la commande hwclock qui sert à ça. Normalement, les distributions prévoient tout le nécessaire, il n'y a rien à toucher.
Le dernier point est important : l'horloge CMOS stocke une heure, pas un instant Unix. Pour que le problème de changement d'heure ne se pose pas, il convient que ce réglage soit fait UTC, qui n'a pas de changement d'heure. Hélas, certains systèmes d'exploitations conçus par des abrutis ne sont pas capables de se synchroniser avec une horloge CMOS en UTC.
[ ~]# hwclock --show dim 16 sep 2007 16:50:50 CEST -0.383127 secondes
Je vois "CEST" et pas "UTC", c'est donc qu'il y a un problème ? :-/
Il faut peut être aussi poser la question suivante : savez vous comment faire pour que PHP (c'est un serveur web qui n'utilise pratiquement que ce langage) fasse bien l'ajustement heure été/hiver lorsque l'on lui demande le résultat de la fonction date() ? Y a t'il une option à vérifier dans le php.ini ?
Ma question toute bête : comment être certain qu'il s'ajustera tout seul à l'heure d'hiver le moment venu ?
Sous Unix, l'heure est comptée uniquement en secondes (non-intercalaires) depuis l'instant de référence du 1970-01-01T00:00:00+0000. La conversion n'est faite qu'au moment où on veut afficher l'heure locale. Dans ces conditions, il n'y a pas d'ajustement qui intervienne : il n'y a rien à changer au moment du changement d'heure, c'est juste la conversion qui donnera un résultat différent.
Comment s'assurer que tout fonctionne bien :
- Vérifier que /etc/localtime est bien identique au fichier de /usr/share/zoneinfo qui convient.
Donc je pense que là c'est bon (suite à l'ajustement via Plesk)
- Si on a un réseau permanent, lancer ntpd pour assurer une synchronisation en continue avec les serveurs de temps.
OK, ça Plesk s'en charge je pense.
- Dans les scripts d'allumage et d'extinction, mettre le nécessaire pour synchroniser l'horloge CMOS avec l'horloge système. C'est la commande hwclock qui sert à ça. Normalement, les distributions prévoient tout le nécessaire, il n'y a rien à toucher.
Le dernier point est important : l'horloge CMOS stocke une heure, pas un instant Unix. Pour que le problème de changement d'heure ne se pose pas, il convient que ce réglage soit fait UTC, qui n'a pas de changement d'heure. Hélas, certains systèmes d'exploitations conçus par des abrutis ne sont pas capables de se synchroniser avec une horloge CMOS en UTC.
[ ~]# hwclock --show dim 16 sep 2007 16:50:50 CEST -0.383127 secondes
Je vois "CEST" et pas "UTC", c'est donc qu'il y a un problème ? :-/
Pas forcément.
man hwclock :
--show Read the Hardware Clock and print the time on Standard Output. The time shown is always in local time, even if you keep your Hardware Clock in Coordinated Universal Time. See the --utc option.
Si ton horloge CMOS a été mise à l'heure en UTC,
hwclock --utc
te donnera la bonne heure locale.
hwclock --localtime
te sortira une heure locale en avance de 2 heures.
Et lycée de Versailles.
-- François Meyer
O.L. <null@undefined.invalid> wrote:
Nicolas George a pensé très fort :
O.L. wrote in message <mn.83cc7d79ab715786.68583@undefined.invalid>:
Ma question toute bête : comment être certain qu'il s'ajustera tout
seul à l'heure d'hiver le moment venu ?
Sous Unix, l'heure est comptée uniquement en secondes (non-intercalaires)
depuis l'instant de référence du 1970-01-01T00:00:00+0000. La conversion
n'est faite qu'au moment où on veut afficher l'heure locale. Dans ces
conditions, il n'y a pas d'ajustement qui intervienne : il n'y a rien à
changer au moment du changement d'heure, c'est juste la conversion qui
donnera un résultat différent.
Comment s'assurer que tout fonctionne bien :
- Vérifier que /etc/localtime est bien identique au fichier de
/usr/share/zoneinfo qui convient.
Donc je pense que là c'est bon (suite à l'ajustement via Plesk)
- Si on a un réseau permanent, lancer ntpd pour assurer une synchronisation
en continue avec les serveurs de temps.
OK, ça Plesk s'en charge je pense.
- Dans les scripts d'allumage et d'extinction, mettre le nécessaire pour
synchroniser l'horloge CMOS avec l'horloge système. C'est la commande
hwclock qui sert à ça. Normalement, les distributions prévoient tout le
nécessaire, il n'y a rien à toucher.
Le dernier point est important : l'horloge CMOS stocke une heure, pas un
instant Unix. Pour que le problème de changement d'heure ne se pose pas, il
convient que ce réglage soit fait UTC, qui n'a pas de changement d'heure.
Hélas, certains systèmes d'exploitations conçus par des abrutis ne sont pas
capables de se synchroniser avec une horloge CMOS en UTC.
[root@nsxxxx ~]# hwclock --show
dim 16 sep 2007 16:50:50 CEST -0.383127 secondes
Je vois "CEST" et pas "UTC", c'est donc qu'il y a un problème ? :-/
Pas forcément.
man hwclock :
--show Read the Hardware Clock and print the time on
Standard Output. The time shown is always in local
time, even if you keep your Hardware Clock in
Coordinated Universal Time. See the --utc option.
Si ton horloge CMOS a été mise à l'heure en UTC,
hwclock --utc
te donnera la bonne heure locale.
hwclock --localtime
te sortira une heure locale en avance de 2 heures.
Ma question toute bête : comment être certain qu'il s'ajustera tout seul à l'heure d'hiver le moment venu ?
Sous Unix, l'heure est comptée uniquement en secondes (non-intercalaires) depuis l'instant de référence du 1970-01-01T00:00:00+0000. La conversion n'est faite qu'au moment où on veut afficher l'heure locale. Dans ces conditions, il n'y a pas d'ajustement qui intervienne : il n'y a rien à changer au moment du changement d'heure, c'est juste la conversion qui donnera un résultat différent.
Comment s'assurer que tout fonctionne bien :
- Vérifier que /etc/localtime est bien identique au fichier de /usr/share/zoneinfo qui convient.
Donc je pense que là c'est bon (suite à l'ajustement via Plesk)
- Si on a un réseau permanent, lancer ntpd pour assurer une synchronisation en continue avec les serveurs de temps.
OK, ça Plesk s'en charge je pense.
- Dans les scripts d'allumage et d'extinction, mettre le nécessaire pour synchroniser l'horloge CMOS avec l'horloge système. C'est la commande hwclock qui sert à ça. Normalement, les distributions prévoient tout le nécessaire, il n'y a rien à toucher.
Le dernier point est important : l'horloge CMOS stocke une heure, pas un instant Unix. Pour que le problème de changement d'heure ne se pose pas, il convient que ce réglage soit fait UTC, qui n'a pas de changement d'heure. Hélas, certains systèmes d'exploitations conçus par des abrutis ne sont pas capables de se synchroniser avec une horloge CMOS en UTC.
[ ~]# hwclock --show dim 16 sep 2007 16:50:50 CEST -0.383127 secondes
Je vois "CEST" et pas "UTC", c'est donc qu'il y a un problème ? :-/
Pas forcément.
man hwclock :
--show Read the Hardware Clock and print the time on Standard Output. The time shown is always in local time, even if you keep your Hardware Clock in Coordinated Universal Time. See the --utc option.
Si ton horloge CMOS a été mise à l'heure en UTC,
hwclock --utc
te donnera la bonne heure locale.
hwclock --localtime
te sortira une heure locale en avance de 2 heures.
Et lycée de Versailles.
-- François Meyer
O.L.
François Meyer a formulé ce lundi :
Si ton horloge CMOS a été mise à l'heure en UTC,
hwclock --utc
te donnera la bonne heure locale.
hwclock --localtime
te sortira une heure locale en avance de 2 heures.
[ ~]# hwclock --utc mar 18 sep 2007 23:12:45 CEST -0.649029 secondes
[ ~]# hwclock --show --utc mar 18 sep 2007 23:13:09 CEST -0.183757 secondes
[ ~]# hwclock --localtime mar 18 sep 2007 21:14:09 CEST -0.041460 secondes
Le localtime est pas en avance de 2 heures, mais en retard ... ça doit pas être bon :-?
[ ~]# hwclock --show --utc mar 18 sep 2007 23:13:09 CEST -0.183757 secondes
[ ~]# hwclock --localtime mar 18 sep 2007 21:14:09 CEST -0.041460 secondes
Le localtime est pas en avance de 2 heures, mais en retard ... ça doit pas être bon :-?
Non, c'est bon. L'horloge CMOS n'a pas d'indication de zone horaire. L'option --utc ou --localtime vient pour remplir cette information. Ici, ton horloge CMOS est à 21:14.
La première commande dit que ce 21:14 est censé être 21:14 UTC, ce qui donne le temps Unix 1190150040, et il est converti à l'affichage en 23:14 CEST.
La deuxième commande dit que ce 21:14 est censé être 21:14 heure locale, soit 21:14 +0200, soit en temps Unix 1190142840, ce qui donne à l'affichage 21:14 CEST.
O.L. wrote in message <mn.94f77d79c6ed7dfa.68583@undefined.invalid>:
[root@nsxxxx ~]# hwclock --show --utc
mar 18 sep 2007 23:13:09 CEST -0.183757 secondes
[root@nsxxxx ~]# hwclock --localtime
mar 18 sep 2007 21:14:09 CEST -0.041460 secondes
Le localtime est pas en avance de 2 heures, mais en retard ... ça doit
pas être bon :-?
Non, c'est bon. L'horloge CMOS n'a pas d'indication de zone horaire.
L'option --utc ou --localtime vient pour remplir cette information. Ici, ton
horloge CMOS est à 21:14.
La première commande dit que ce 21:14 est censé être 21:14 UTC, ce qui donne
le temps Unix 1190150040, et il est converti à l'affichage en 23:14 CEST.
La deuxième commande dit que ce 21:14 est censé être 21:14 heure locale,
soit 21:14 +0200, soit en temps Unix 1190142840, ce qui donne à l'affichage
21:14 CEST.
[ ~]# hwclock --show --utc mar 18 sep 2007 23:13:09 CEST -0.183757 secondes
[ ~]# hwclock --localtime mar 18 sep 2007 21:14:09 CEST -0.041460 secondes
Le localtime est pas en avance de 2 heures, mais en retard ... ça doit pas être bon :-?
Non, c'est bon. L'horloge CMOS n'a pas d'indication de zone horaire. L'option --utc ou --localtime vient pour remplir cette information. Ici, ton horloge CMOS est à 21:14.
La première commande dit que ce 21:14 est censé être 21:14 UTC, ce qui donne le temps Unix 1190150040, et il est converti à l'affichage en 23:14 CEST.
La deuxième commande dit que ce 21:14 est censé être 21:14 heure locale, soit 21:14 +0200, soit en temps Unix 1190142840, ce qui donne à l'affichage 21:14 CEST.
O.L.
Nicolas George avait énoncé :
O.L. wrote in message :
[ ~]# hwclock --show --utc mar 18 sep 2007 23:13:09 CEST -0.183757 secondes
[ ~]# hwclock --localtime mar 18 sep 2007 21:14:09 CEST -0.041460 secondes
Le localtime est pas en avance de 2 heures, mais en retard ... ça doit pas être bon :-?
Non, c'est bon. L'horloge CMOS n'a pas d'indication de zone horaire. L'option --utc ou --localtime vient pour remplir cette information. Ici, ton horloge CMOS est à 21:14.
La première commande dit que ce 21:14 est censé être 21:14 UTC, ce qui donne le temps Unix 1190150040, et il est converti à l'affichage en 23:14 CEST.
La deuxième commande dit que ce 21:14 est censé être 21:14 heure locale, soit 21:14 +0200, soit en temps Unix 1190142840, ce qui donne à l'affichage 21:14 CEST.
OK ! Et savez vous comment je peux être sûr que le passage heure été=>hiver se fera correctement dans les scripts PHP ?
O.L. wrote in message <mn.94f77d79c6ed7dfa.68583@undefined.invalid>:
[root@nsxxxx ~]# hwclock --show --utc
mar 18 sep 2007 23:13:09 CEST -0.183757 secondes
[root@nsxxxx ~]# hwclock --localtime
mar 18 sep 2007 21:14:09 CEST -0.041460 secondes
Le localtime est pas en avance de 2 heures, mais en retard ... ça doit
pas être bon :-?
Non, c'est bon. L'horloge CMOS n'a pas d'indication de zone horaire.
L'option --utc ou --localtime vient pour remplir cette information. Ici, ton
horloge CMOS est à 21:14.
La première commande dit que ce 21:14 est censé être 21:14 UTC, ce qui donne
le temps Unix 1190150040, et il est converti à l'affichage en 23:14 CEST.
La deuxième commande dit que ce 21:14 est censé être 21:14 heure locale,
soit 21:14 +0200, soit en temps Unix 1190142840, ce qui donne à l'affichage
21:14 CEST.
OK !
Et savez vous comment je peux être sûr que le passage heure été=>hiver
se fera correctement dans les scripts PHP ?
[ ~]# hwclock --show --utc mar 18 sep 2007 23:13:09 CEST -0.183757 secondes
[ ~]# hwclock --localtime mar 18 sep 2007 21:14:09 CEST -0.041460 secondes
Le localtime est pas en avance de 2 heures, mais en retard ... ça doit pas être bon :-?
Non, c'est bon. L'horloge CMOS n'a pas d'indication de zone horaire. L'option --utc ou --localtime vient pour remplir cette information. Ici, ton horloge CMOS est à 21:14.
La première commande dit que ce 21:14 est censé être 21:14 UTC, ce qui donne le temps Unix 1190150040, et il est converti à l'affichage en 23:14 CEST.
La deuxième commande dit que ce 21:14 est censé être 21:14 heure locale, soit 21:14 +0200, soit en temps Unix 1190142840, ce qui donne à l'affichage 21:14 CEST.
OK ! Et savez vous comment je peux être sûr que le passage heure été=>hiver se fera correctement dans les scripts PHP ?