Tiens, je remarque que mon serveur est passé de l'heure d'été à l'heure
d'hiver, tout seul comme un grand.
Je suis étonné parce que je n'ai pas activé de NTP.
Les routines intègrent le changement de saison, en fonction du fuseau
horaire ?
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
Erwan David
gregg écrivait :
Tiens, je remarque que mon serveur est passé de l'heure d'été à l'heure d'hiver, tout seul comme un grand. Je suis étonné parce que je n'ai pas activé de NTP. Les routines intègrent le changement de saison, en fonction du fuseau horaire ?
Oui. En fait la manière de faire ça c'est de laisser l'horloge interne en UTC et de convertir à l'affichage (ce qui ne demande que de connaitre les dates de changement d'heure légale).
FreeBSD a un système permettant de laisser l'horloge interne en heure locale pour le cas où il est en double boot avec un système qui ne comprends rien au problème des fuseaux horaires. Mais c'est pas la configuration conseillée.
Tiens, je remarque que mon serveur est passé de l'heure d'été à
l'heure d'hiver, tout seul comme un grand.
Je suis étonné parce que je n'ai pas activé de NTP.
Les routines intègrent le changement de saison, en fonction du fuseau
horaire ?
Oui. En fait la manière de faire ça c'est de laisser
l'horloge interne en UTC et de convertir à l'affichage (ce qui ne
demande que de connaitre les dates de changement d'heure légale).
FreeBSD a un système permettant de laisser l'horloge interne en heure
locale pour le cas où il est en double boot avec un système qui ne
comprends rien au problème des fuseaux horaires. Mais c'est pas la
configuration conseillée.
Tiens, je remarque que mon serveur est passé de l'heure d'été à l'heure d'hiver, tout seul comme un grand. Je suis étonné parce que je n'ai pas activé de NTP. Les routines intègrent le changement de saison, en fonction du fuseau horaire ?
Oui. En fait la manière de faire ça c'est de laisser l'horloge interne en UTC et de convertir à l'affichage (ce qui ne demande que de connaitre les dates de changement d'heure légale).
FreeBSD a un système permettant de laisser l'horloge interne en heure locale pour le cas où il est en double boot avec un système qui ne comprends rien au problème des fuseaux horaires. Mais c'est pas la configuration conseillée.
-- Erwan
Jacques Caron
Salut,
On Tue, 28 Oct 2003 11:08:08 +0100, gregg wrote:
Tiens, je remarque que mon serveur est passé de l'heure d'été à l'heure d'hiver, tout seul comme un grand.
Normal.
Je suis étonné parce que je n'ai pas activé de NTP.
Pas besoin, et ça ne changerait rien.
Les routines intègrent le changement de saison, en fonction du fuseau horaire ?
Tous les systèmes Unix maintiennent le temps en UTC (ou GMT), en secondes depuis une date de référence (le 1er janvier 1970). Cette "heure" de référence a l'avantage qu'elle est très facile à manipuler, et qu'elle est parfaitement linéaire: elle augmente de 1 seconde par seconde :-)
Ensuite, quand tu fais un affichage avec les librairies standard, tu as le choix entre afficher l'heure en GMT, ou l'heure locale en fonction du fuseau horaire (la "timezone"), qui inclut la définition des heures d'hiver et d'été. La version traditionnelle c'était la variable d'environnement TZ avec un format plus ou moins complexe, maintenant c'est le fichier /etc/localtime.
Et NTP ne changerait rien, parce que NTP maintient le temps en UTC lui aussi, encore heureux.
Magique :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Tue, 28 Oct 2003 11:08:08 +0100, gregg
<greggory@netJUSTSAYNOcourrier.com> wrote:
Tiens, je remarque que mon serveur est passé de l'heure d'été à l'heure
d'hiver, tout seul comme un grand.
Normal.
Je suis étonné parce que je n'ai pas activé de NTP.
Pas besoin, et ça ne changerait rien.
Les routines intègrent le changement de saison, en fonction du fuseau
horaire ?
Tous les systèmes Unix maintiennent le temps en UTC (ou GMT), en secondes
depuis une date de référence (le 1er janvier 1970). Cette "heure" de
référence a l'avantage qu'elle est très facile à manipuler, et qu'elle est
parfaitement linéaire: elle augmente de 1 seconde par seconde :-)
Ensuite, quand tu fais un affichage avec les librairies standard, tu as le
choix entre afficher l'heure en GMT, ou l'heure locale en fonction du
fuseau horaire (la "timezone"), qui inclut la définition des heures
d'hiver et d'été. La version traditionnelle c'était la variable
d'environnement TZ avec un format plus ou moins complexe, maintenant c'est
le fichier /etc/localtime.
Et NTP ne changerait rien, parce que NTP maintient le temps en UTC lui
aussi, encore heureux.
Magique :-)
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Tiens, je remarque que mon serveur est passé de l'heure d'été à l'heure d'hiver, tout seul comme un grand.
Normal.
Je suis étonné parce que je n'ai pas activé de NTP.
Pas besoin, et ça ne changerait rien.
Les routines intègrent le changement de saison, en fonction du fuseau horaire ?
Tous les systèmes Unix maintiennent le temps en UTC (ou GMT), en secondes depuis une date de référence (le 1er janvier 1970). Cette "heure" de référence a l'avantage qu'elle est très facile à manipuler, et qu'elle est parfaitement linéaire: elle augmente de 1 seconde par seconde :-)
Ensuite, quand tu fais un affichage avec les librairies standard, tu as le choix entre afficher l'heure en GMT, ou l'heure locale en fonction du fuseau horaire (la "timezone"), qui inclut la définition des heures d'hiver et d'été. La version traditionnelle c'était la variable d'environnement TZ avec un format plus ou moins complexe, maintenant c'est le fichier /etc/localtime.
Et NTP ne changerait rien, parce que NTP maintient le temps en UTC lui aussi, encore heureux.
Magique :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
gregg
Erwan David wrote:
Oui. En fait la manière de faire ça c'est de laisser l'horloge interne en UTC et de convertir à l'affichage (ce qui ne demande que de connaitre les dates de changement d'heure légale).
FreeBSD a un système permettant de laisser l'horloge interne en heure locale pour le cas où il est en double boot avec un système qui ne comprends rien au problème des fuseaux horaires. Mais c'est pas la configuration conseillée.
FreeBSD est le seul système, et je place l'horloge BIOS en UTC systématiquement (même sur la machine dual-boot windows).
J'ai été étonné que l'heure soit automatiquement changée par le simple positionnement d'une variable fuseau horaire (encore que, comme le post de Jacques le précise, ce n'est plus TZ).
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
(et merci pour les réponses :)
gregg
Erwan David wrote:
Oui. En fait la manière de faire ça c'est de laisser
l'horloge interne en UTC et de convertir à l'affichage (ce qui ne
demande que de connaitre les dates de changement d'heure légale).
FreeBSD a un système permettant de laisser l'horloge interne en heure
locale pour le cas où il est en double boot avec un système qui ne
comprends rien au problème des fuseaux horaires. Mais c'est pas la
configuration conseillée.
FreeBSD est le seul système, et je place l'horloge BIOS en UTC
systématiquement (même sur la machine dual-boot windows).
J'ai été étonné que l'heure soit automatiquement changée par le simple
positionnement d'une variable fuseau horaire (encore que, comme le post
de Jacques le précise, ce n'est plus TZ).
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
Oui. En fait la manière de faire ça c'est de laisser l'horloge interne en UTC et de convertir à l'affichage (ce qui ne demande que de connaitre les dates de changement d'heure légale).
FreeBSD a un système permettant de laisser l'horloge interne en heure locale pour le cas où il est en double boot avec un système qui ne comprends rien au problème des fuseaux horaires. Mais c'est pas la configuration conseillée.
FreeBSD est le seul système, et je place l'horloge BIOS en UTC systématiquement (même sur la machine dual-boot windows).
J'ai été étonné que l'heure soit automatiquement changée par le simple positionnement d'une variable fuseau horaire (encore que, comme le post de Jacques le précise, ce n'est plus TZ).
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
(et merci pour les réponses :)
gregg
Stephane Dupille
FreeBSD est le seul système, et je place l'horloge BIOS en UTC systématiquement (même sur la machine dual-boot windows).
Si l'horloge est en UTC, il n'y a pas d'heure d'été, on n'a pas besoin de la changer.
J'ai été étonné que l'heure soit automatiquement changée par le simple positionnement d'une variable fuseau horaire (encore que, comme le post de Jacques le précise, ce n'est plus TZ).
Ce n'est pas une variable d'environnement, c'est /etc/localtime. Et ce dernier ne change pas. Ce fichier indique simplement les dates de changement d'heures d'été/hiver, si applicable.
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
Non, elle n'est pas changée. En UTC, il n'y a pas d'heure d'été et d'hiver. On a par ailleurs, indiqué au système dans quel fuseau horaire on se trouve, en général, cela se fait au moment de l'install.
Toutes les commandes qui manipulent l'heure regardent dans quel fuseau horaire on se trouve pour calculer l'heure locale à partir de l'horloge (qui est en UTC).
Donc l'horloge ne passe pas à l'heure d'été/hiver, mais les commandes qui manipulent l'heure savent si on est en période d'heure d'été (DST) ou non, et donc savent s'il faut appliquer la modification +1 ou +2.
Donc l'horloge ne bouge pas, c'est simplement la commande qui permet de récupérer la date qui ajoute +1h au lieu de +2h l'été.
(et merci pour les réponses :)
De rien.
-- Quel est le MEILLEUR SITE avec une tonne de Javascript's que vous connaissez ?? -+- Titeuf in GNU : C'est fou ce qu'on s'oxymore ici -+-
FreeBSD est le seul système, et je place l'horloge BIOS en UTC
systématiquement (même sur la machine dual-boot windows).
Si l'horloge est en UTC, il n'y a pas d'heure d'été, on n'a pas
besoin de la changer.
J'ai été étonné que l'heure soit automatiquement changée par le simple
positionnement d'une variable fuseau horaire (encore que, comme le
post de Jacques le précise, ce n'est plus TZ).
Ce n'est pas une variable d'environnement, c'est /etc/localtime. Et
ce dernier ne change pas. Ce fichier indique simplement les dates de
changement d'heures d'été/hiver, si applicable.
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
Non, elle n'est pas changée. En UTC, il n'y a pas d'heure d'été et
d'hiver. On a par ailleurs, indiqué au système dans quel fuseau
horaire on se trouve, en général, cela se fait au moment de l'install.
Toutes les commandes qui manipulent l'heure regardent dans quel
fuseau horaire on se trouve pour calculer l'heure locale à partir de
l'horloge (qui est en UTC).
Donc l'horloge ne passe pas à l'heure d'été/hiver, mais les
commandes qui manipulent l'heure savent si on est en période d'heure
d'été (DST) ou non, et donc savent s'il faut appliquer la modification
+1 ou +2.
Donc l'horloge ne bouge pas, c'est simplement la commande qui permet
de récupérer la date qui ajoute +1h au lieu de +2h l'été.
(et merci pour les réponses :)
De rien.
--
Quel est le MEILLEUR SITE avec une tonne de Javascript's que vous
connaissez ??
-+- Titeuf in GNU : C'est fou ce qu'on s'oxymore ici -+-
FreeBSD est le seul système, et je place l'horloge BIOS en UTC systématiquement (même sur la machine dual-boot windows).
Si l'horloge est en UTC, il n'y a pas d'heure d'été, on n'a pas besoin de la changer.
J'ai été étonné que l'heure soit automatiquement changée par le simple positionnement d'une variable fuseau horaire (encore que, comme le post de Jacques le précise, ce n'est plus TZ).
Ce n'est pas une variable d'environnement, c'est /etc/localtime. Et ce dernier ne change pas. Ce fichier indique simplement les dates de changement d'heures d'été/hiver, si applicable.
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
Non, elle n'est pas changée. En UTC, il n'y a pas d'heure d'été et d'hiver. On a par ailleurs, indiqué au système dans quel fuseau horaire on se trouve, en général, cela se fait au moment de l'install.
Toutes les commandes qui manipulent l'heure regardent dans quel fuseau horaire on se trouve pour calculer l'heure locale à partir de l'horloge (qui est en UTC).
Donc l'horloge ne passe pas à l'heure d'été/hiver, mais les commandes qui manipulent l'heure savent si on est en période d'heure d'été (DST) ou non, et donc savent s'il faut appliquer la modification +1 ou +2.
Donc l'horloge ne bouge pas, c'est simplement la commande qui permet de récupérer la date qui ajoute +1h au lieu de +2h l'été.
(et merci pour les réponses :)
De rien.
-- Quel est le MEILLEUR SITE avec une tonne de Javascript's que vous connaissez ?? -+- Titeuf in GNU : C'est fou ce qu'on s'oxymore ici -+-
Jacques Caron
On Tue, 28 Oct 2003 11:52:59 +0100, gregg wrote:
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
Non. Il n'y a pas de changement d'heure en fait, pour le système on est passé de la date 1067129999 à la date 1067130000 (nombre de secondes depuis le 1er janvier 1970 à 0:00 GMT). C'est juste que les fonctions d'affichage, en tenant compte du fuseau horaire, savent que ces dates correspondent respectivement à 2:59:59 heure d'été et 2:00:00 heure d'hiver.
Tu peux d'ailleurs le voir comme ça:
date -r 1067129999 Dim 26 oct 2003 02:59:59 CEST
date -r 1067130000 Dim 26 oct 2003 02:00:00 CET
En interne, il continue à comter en GMT/UTC. Ce n'est que l'affichage qui compte. Et d'ailleurs, si tu avais sur ton système des utilisateurs loggués depuis des fuseaux horaires différents, ils pourraient avoir chacun leur valeur de TZ, et chacun "verrait" une heure différente, alors que le système continue à avoir la même heure GMT/UTC pour tout le monde en interne.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Tue, 28 Oct 2003 11:52:59 +0100, gregg
<greggory@netJUSTSAYNOcourrier.com> wrote:
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
Non. Il n'y a pas de changement d'heure en fait, pour le système on est
passé de la date 1067129999 à la date 1067130000 (nombre de secondes
depuis le 1er janvier 1970 à 0:00 GMT). C'est juste que les fonctions
d'affichage, en tenant compte du fuseau horaire, savent que ces dates
correspondent respectivement à 2:59:59 heure d'été et 2:00:00 heure
d'hiver.
Tu peux d'ailleurs le voir comme ça:
date -r 1067129999
Dim 26 oct 2003 02:59:59 CEST
date -r 1067130000
Dim 26 oct 2003 02:00:00 CET
En interne, il continue à comter en GMT/UTC. Ce n'est que l'affichage qui
compte. Et d'ailleurs, si tu avais sur ton système des utilisateurs
loggués depuis des fuseaux horaires différents, ils pourraient avoir
chacun leur valeur de TZ, et chacun "verrait" une heure différente, alors
que le système continue à avoir la même heure GMT/UTC pour tout le monde
en interne.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
Non. Il n'y a pas de changement d'heure en fait, pour le système on est passé de la date 1067129999 à la date 1067130000 (nombre de secondes depuis le 1er janvier 1970 à 0:00 GMT). C'est juste que les fonctions d'affichage, en tenant compte du fuseau horaire, savent que ces dates correspondent respectivement à 2:59:59 heure d'été et 2:00:00 heure d'hiver.
Tu peux d'ailleurs le voir comme ça:
date -r 1067129999 Dim 26 oct 2003 02:59:59 CEST
date -r 1067130000 Dim 26 oct 2003 02:00:00 CET
En interne, il continue à comter en GMT/UTC. Ce n'est que l'affichage qui compte. Et d'ailleurs, si tu avais sur ton système des utilisateurs loggués depuis des fuseaux horaires différents, ils pourraient avoir chacun leur valeur de TZ, et chacun "verrait" une heure différente, alors que le système continue à avoir la même heure GMT/UTC pour tout le monde en interne.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Erwan David
gregg écrivait :
Erwan David wrote:
Oui. En fait la manière de faire ça c'est de laisser l'horloge interne en UTC et de convertir à l'affichage (ce qui ne demande que de connaitre les dates de changement d'heure légale). FreeBSD a un système permettant de laisser l'horloge interne en heure locale pour le cas où il est en double boot avec un système qui ne comprends rien au problème des fuseaux horaires. Mais c'est pas la configuration conseillée.
FreeBSD est le seul système, et je place l'horloge BIOS en UTC systématiquement (même sur la machine dual-boot windows).
J'ai été étonné que l'heure soit automatiquement changée par le simple positionnement d'une variable fuseau horaire (encore que, comme le post de Jacques le précise, ce n'est plus TZ).
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
Non, ton horloge est restée en UTC. Simplement la fonction de conversion UTC->heure locale sais à partir de l'heure UTC et de la timezone quel est le décalage.
Oui. En fait la manière de faire ça c'est de laisser
l'horloge interne en UTC et de convertir à l'affichage (ce qui ne
demande que de connaitre les dates de changement d'heure légale).
FreeBSD a un système permettant de laisser l'horloge interne en heure
locale pour le cas où il est en double boot avec un système qui ne
comprends rien au problème des fuseaux horaires. Mais c'est pas la
configuration conseillée.
FreeBSD est le seul système, et je place l'horloge BIOS en UTC
systématiquement (même sur la machine dual-boot windows).
J'ai été étonné que l'heure soit automatiquement changée par le simple
positionnement d'une variable fuseau horaire (encore que, comme le
post de Jacques le précise, ce n'est plus TZ).
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
Non, ton horloge est restée en UTC. Simplement la fonction de
conversion UTC->heure locale sais à partir de l'heure UTC et de la
timezone quel est le décalage.
Oui. En fait la manière de faire ça c'est de laisser l'horloge interne en UTC et de convertir à l'affichage (ce qui ne demande que de connaitre les dates de changement d'heure légale). FreeBSD a un système permettant de laisser l'horloge interne en heure locale pour le cas où il est en double boot avec un système qui ne comprends rien au problème des fuseaux horaires. Mais c'est pas la configuration conseillée.
FreeBSD est le seul système, et je place l'horloge BIOS en UTC systématiquement (même sur la machine dual-boot windows).
J'ai été étonné que l'heure soit automatiquement changée par le simple positionnement d'une variable fuseau horaire (encore que, comme le post de Jacques le précise, ce n'est plus TZ).
Du fait, le changement à 3h pile est intervenu sur ordre de cron, alors ?
Non, ton horloge est restée en UTC. Simplement la fonction de conversion UTC->heure locale sais à partir de l'heure UTC et de la timezone quel est le décalage.
-- Erwan
Jacques Caron
Re,
On Tue, 28 Oct 2003 12:15:36 +0100, Jacques Caron wrote:
En interne, il continue à comter en GMT/UTC. Ce n'est que l'affichage qui compte. Et d'ailleurs, si tu avais sur ton système des utilisateurs loggués depuis des fuseaux horaires différents, ils pourraient avoir chacun leur valeur de TZ, et chacun "verrait" une heure différente, alors que le système continue à avoir la même heure GMT/UTC pour tout le monde en interne.
Et pour illustrer ça:
date Mar 28 oct 2003 12:22:27 CET
Utilise /etc/localtime et me donne la date "locale" chez moi, i.e. l'heure d'hiver pour la France.
date -u Mar 28 oct 2003 11:22:29 UTC
Ca c'est la date UTC maintenue en interne.
setenv TZ EST6EDT
Je lui dis que je suis en fait sur la côte est des Etats-Unis...
date Mar 28 oct 2003 05:22:37 EST
Et il me donne la date là-bas...
date -u Mar 28 oct 2003 11:22:38 UTC
Mais la date UTC est bien entendu inchangée...
setenv TZ PST9PDT
Idem côte ouest des US...
date Mar 28 oct 2003 02:22:46 PST
date -u Mar 28 oct 2003 11:22:47 UTC
Date UTC toujours pareil...
unsetenv TZ
Je lui dis de faire de nouveau confiance à /etc/localtime
Tu peux t'amuser à ouvrir deux sessions différentes. Tu fais setenv TZ EST6EDT dans l'une, et tu tapes date sur les deux. Chaque session te donnera une heure différente...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Re,
On Tue, 28 Oct 2003 12:15:36 +0100, Jacques Caron <jc@imfeurope.com> wrote:
En interne, il continue à comter en GMT/UTC. Ce n'est que l'affichage
qui compte. Et d'ailleurs, si tu avais sur ton système des utilisateurs
loggués depuis des fuseaux horaires différents, ils pourraient avoir
chacun leur valeur de TZ, et chacun "verrait" une heure différente,
alors que le système continue à avoir la même heure GMT/UTC pour tout le
monde en interne.
Et pour illustrer ça:
date
Mar 28 oct 2003 12:22:27 CET
Utilise /etc/localtime et me donne la date "locale" chez moi, i.e. l'heure
d'hiver pour la France.
date -u
Mar 28 oct 2003 11:22:29 UTC
Ca c'est la date UTC maintenue en interne.
setenv TZ EST6EDT
Je lui dis que je suis en fait sur la côte est des Etats-Unis...
date
Mar 28 oct 2003 05:22:37 EST
Et il me donne la date là-bas...
date -u
Mar 28 oct 2003 11:22:38 UTC
Mais la date UTC est bien entendu inchangée...
setenv TZ PST9PDT
Idem côte ouest des US...
date
Mar 28 oct 2003 02:22:46 PST
date -u
Mar 28 oct 2003 11:22:47 UTC
Date UTC toujours pareil...
unsetenv TZ
Je lui dis de faire de nouveau confiance à /etc/localtime
Tu peux t'amuser à ouvrir deux sessions différentes. Tu fais setenv TZ
EST6EDT dans l'une, et tu tapes date sur les deux. Chaque session te
donnera une heure différente...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Tue, 28 Oct 2003 12:15:36 +0100, Jacques Caron wrote:
En interne, il continue à comter en GMT/UTC. Ce n'est que l'affichage qui compte. Et d'ailleurs, si tu avais sur ton système des utilisateurs loggués depuis des fuseaux horaires différents, ils pourraient avoir chacun leur valeur de TZ, et chacun "verrait" une heure différente, alors que le système continue à avoir la même heure GMT/UTC pour tout le monde en interne.
Et pour illustrer ça:
date Mar 28 oct 2003 12:22:27 CET
Utilise /etc/localtime et me donne la date "locale" chez moi, i.e. l'heure d'hiver pour la France.
date -u Mar 28 oct 2003 11:22:29 UTC
Ca c'est la date UTC maintenue en interne.
setenv TZ EST6EDT
Je lui dis que je suis en fait sur la côte est des Etats-Unis...
date Mar 28 oct 2003 05:22:37 EST
Et il me donne la date là-bas...
date -u Mar 28 oct 2003 11:22:38 UTC
Mais la date UTC est bien entendu inchangée...
setenv TZ PST9PDT
Idem côte ouest des US...
date Mar 28 oct 2003 02:22:46 PST
date -u Mar 28 oct 2003 11:22:47 UTC
Date UTC toujours pareil...
unsetenv TZ
Je lui dis de faire de nouveau confiance à /etc/localtime
Tu peux t'amuser à ouvrir deux sessions différentes. Tu fais setenv TZ EST6EDT dans l'une, et tu tapes date sur les deux. Chaque session te donnera une heure différente...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
