Donne une heure right/UTC en *retard* de 22 secondes par rapport au vrai UTC, qui ne correspondent à rien d'évident. Et donc là je ne comprends vraiment pas ce que ce répertoire right contient.
22 est le nombre de secondes intercalaires ajoutées depuis 1972, date de l'adoption du système UTC avec secondes intercalaires.
Oui, mais si right/UTC fait référence à TAI+10 (UTC tel qu'il était en 1972), il devrait être en avance de 22 secondes.
Je suppose que le temps right/UTC est donc le temps correct qui tient compte des secondes intercalaires, à opposer au temps Unix qui n'en tient pas compte.
Ok, cappice. Mais donc parmi les 2 zoneinfo/UTC et zoneinfo/right/UTC, s'il y en a une qui se rapporte à TAI (et encore pas exactement mais à TAI+10s) c'est bien zoneinfo/UTC et pas zoneinfo/right/UTC.
Me voilà à la tête d'un lot de quart de cheveux. Ca intéresse quelqu'un ? -- francois meyer
Richard Delorme <abulmo@nospam.fr> wrote:
Richard Delorme <abulmo@nospam.fr> wrote:
Donne une heure right/UTC en *retard* de 22
secondes par rapport au vrai UTC, qui ne
correspondent à rien d'évident. Et donc là je ne
comprends vraiment pas ce que ce répertoire right
contient.
22 est le nombre de secondes intercalaires ajoutées depuis 1972, date de
l'adoption du système UTC avec secondes intercalaires.
Oui, mais si right/UTC fait référence à TAI+10 (UTC tel qu'il
était en 1972), il devrait être en avance de 22 secondes.
Je suppose que le temps right/UTC est donc le temps correct qui tient
compte des secondes intercalaires, à opposer au temps Unix qui n'en
tient pas compte.
Ok, cappice. Mais donc parmi les 2 zoneinfo/UTC et zoneinfo/right/UTC,
s'il y en a une qui se rapporte à TAI (et encore pas exactement
mais à TAI+10s) c'est bien zoneinfo/UTC et pas zoneinfo/right/UTC.
Me voilà à la tête d'un lot de quart de cheveux. Ca intéresse quelqu'un ?
-- francois meyer
Donne une heure right/UTC en *retard* de 22 secondes par rapport au vrai UTC, qui ne correspondent à rien d'évident. Et donc là je ne comprends vraiment pas ce que ce répertoire right contient.
22 est le nombre de secondes intercalaires ajoutées depuis 1972, date de l'adoption du système UTC avec secondes intercalaires.
Oui, mais si right/UTC fait référence à TAI+10 (UTC tel qu'il était en 1972), il devrait être en avance de 22 secondes.
Je suppose que le temps right/UTC est donc le temps correct qui tient compte des secondes intercalaires, à opposer au temps Unix qui n'en tient pas compte.
Ok, cappice. Mais donc parmi les 2 zoneinfo/UTC et zoneinfo/right/UTC, s'il y en a une qui se rapporte à TAI (et encore pas exactement mais à TAI+10s) c'est bien zoneinfo/UTC et pas zoneinfo/right/UTC.
Me voilà à la tête d'un lot de quart de cheveux. Ca intéresse quelqu'un ? -- francois meyer
Nicolas George
wrote in message <cmvdse$8r5$:
Ok, cappice. Mais donc parmi les 2 zoneinfo/UTC et zoneinfo/right/UTC, s'il y en a une qui se rapporte à TAI (et encore pas exactement mais à TAI+10s) c'est bien zoneinfo/UTC et pas zoneinfo/right/UTC.
Je ne comprends pas très bien ce que vous voulez dire ici, mais j'ai l'impression que vous prenez encore le problème à l'envers.
Il faut bien voir une chose : si le choix de la zone horaire est quelque chose qui concerne l'utilisateur (si je me logue sur un ordinateur en France depuis New York par ssh, je suis tout à fait fondé à faire un TZ=America/New_York pour régler l'affichage de l'heure dans mes programmes.
Le choix entre « right » et pas « right », en revanche, est un choix d'administration, et doit refléter comment est effectivement réglé le compteur du noyau. De ce point de vue, d'ailleurs, l'interface de la glibc est mal faite, puisque moi, simple utilisateur me loguant depuis New York, je suis au final obligé de savoir quelle décision a prise l'administrateur pour savoir si je dois mettre TZ=America/New_York ou TZ=right/America/New_York.
Mais au final, c'est un réglage interne. La partie visible, c'est que quand on tape « date », c'est l'heure légale actuelle qui doit s'afficher, indépendemment du fait qu'en interne ce soit réglé sur « right » ou pas. Et de ce point de vue, la timezone « UTC » est une heure légale comme une autre.
Considérons deux ordinateurs, A réglé de manière traditionnelle sur UTC, B réglé sur right/UTC, avec dans les deux cas le compteur du noyau correctement réglé en conséquence. Si on tape « date » sur A et B au même moment, ou va obtenir dans les deux cas, par exemple « Thu Nov 11 18:17:13 UTC 2004 ». Parce que c'est le même moment, c'est le même UTC qui s'affiche. En revanche, si on avait tapé « date +%s » pour connaître la valeur du compteur interne, on aurait eu sur A « 1100197033 » et sur B « 1100197055 ».
fm@nowhere.invalid wrote in message <cmvdse$8r5$4@ccpntc8.in2p3.fr>:
Ok, cappice. Mais donc parmi les 2 zoneinfo/UTC et zoneinfo/right/UTC,
s'il y en a une qui se rapporte à TAI (et encore pas exactement
mais à TAI+10s) c'est bien zoneinfo/UTC et pas zoneinfo/right/UTC.
Je ne comprends pas très bien ce que vous voulez dire ici, mais j'ai
l'impression que vous prenez encore le problème à l'envers.
Il faut bien voir une chose : si le choix de la zone horaire est quelque
chose qui concerne l'utilisateur (si je me logue sur un ordinateur en France
depuis New York par ssh, je suis tout à fait fondé à faire un
TZ=America/New_York pour régler l'affichage de l'heure dans mes programmes.
Le choix entre « right » et pas « right », en revanche, est un choix
d'administration, et doit refléter comment est effectivement réglé le
compteur du noyau. De ce point de vue, d'ailleurs, l'interface de la glibc
est mal faite, puisque moi, simple utilisateur me loguant depuis New York,
je suis au final obligé de savoir quelle décision a prise l'administrateur
pour savoir si je dois mettre TZ=America/New_York ou
TZ=right/America/New_York.
Mais au final, c'est un réglage interne. La partie visible, c'est que quand
on tape « date », c'est l'heure légale actuelle qui doit s'afficher,
indépendemment du fait qu'en interne ce soit réglé sur « right » ou pas. Et
de ce point de vue, la timezone « UTC » est une heure légale comme une
autre.
Considérons deux ordinateurs, A réglé de manière traditionnelle sur UTC, B
réglé sur right/UTC, avec dans les deux cas le compteur du noyau
correctement réglé en conséquence. Si on tape « date » sur A et B au même
moment, ou va obtenir dans les deux cas, par exemple « Thu Nov 11 18:17:13
UTC 2004 ». Parce que c'est le même moment, c'est le même UTC qui s'affiche.
En revanche, si on avait tapé « date +%s » pour connaître la valeur du
compteur interne, on aurait eu sur A « 1100197033 » et sur B « 1100197055 ».
Ok, cappice. Mais donc parmi les 2 zoneinfo/UTC et zoneinfo/right/UTC, s'il y en a une qui se rapporte à TAI (et encore pas exactement mais à TAI+10s) c'est bien zoneinfo/UTC et pas zoneinfo/right/UTC.
Je ne comprends pas très bien ce que vous voulez dire ici, mais j'ai l'impression que vous prenez encore le problème à l'envers.
Il faut bien voir une chose : si le choix de la zone horaire est quelque chose qui concerne l'utilisateur (si je me logue sur un ordinateur en France depuis New York par ssh, je suis tout à fait fondé à faire un TZ=America/New_York pour régler l'affichage de l'heure dans mes programmes.
Le choix entre « right » et pas « right », en revanche, est un choix d'administration, et doit refléter comment est effectivement réglé le compteur du noyau. De ce point de vue, d'ailleurs, l'interface de la glibc est mal faite, puisque moi, simple utilisateur me loguant depuis New York, je suis au final obligé de savoir quelle décision a prise l'administrateur pour savoir si je dois mettre TZ=America/New_York ou TZ=right/America/New_York.
Mais au final, c'est un réglage interne. La partie visible, c'est que quand on tape « date », c'est l'heure légale actuelle qui doit s'afficher, indépendemment du fait qu'en interne ce soit réglé sur « right » ou pas. Et de ce point de vue, la timezone « UTC » est une heure légale comme une autre.
Considérons deux ordinateurs, A réglé de manière traditionnelle sur UTC, B réglé sur right/UTC, avec dans les deux cas le compteur du noyau correctement réglé en conséquence. Si on tape « date » sur A et B au même moment, ou va obtenir dans les deux cas, par exemple « Thu Nov 11 18:17:13 UTC 2004 ». Parce que c'est le même moment, c'est le même UTC qui s'affiche. En revanche, si on avait tapé « date +%s » pour connaître la valeur du compteur interne, on aurait eu sur A « 1100197033 » et sur B « 1100197055 ».
fm
Nicolas George <nicolas$ wrote:
wrote in message <cmvdse$8r5$:
Ok, cappice. Mais donc parmi les 2 zoneinfo/UTC et zoneinfo/right/UTC, s'il y en a une qui se rapporte à TAI (et encore pas exactement mais à TAI+10s) c'est bien zoneinfo/UTC et pas zoneinfo/right/UTC.
Je ne comprends pas très bien ce que vous voulez dire ici, mais j'ai l'impression que vous prenez encore le problème à l'envers.
Exact, il me restait effectivement un scrupule à évacuer.
Cette fois c'est clair.
Ceci dit la phrase :
"...préfèrent avoir une horloge unix calée sur TAI"
est ambigüe parce que l'horloge suit effectivement TAI mais est décalée de 10s.
En fait, quand on fait un choix comme celui-ci, on ne recherche pas le calage sur telle ou telle échelle de temps, mais bel et bien le fait d'avoir une horloge unix uniforme c'est à dire une succession de valeurs du compteur formant une suite continue sans sauts ni doublons.
-- francois meyer
Nicolas George <nicolas$george@salle-s.org> wrote:
fm@nowhere.invalid wrote in message <cmvdse$8r5$4@ccpntc8.in2p3.fr>:
Ok, cappice. Mais donc parmi les 2 zoneinfo/UTC et zoneinfo/right/UTC,
s'il y en a une qui se rapporte à TAI (et encore pas exactement
mais à TAI+10s) c'est bien zoneinfo/UTC et pas zoneinfo/right/UTC.
Je ne comprends pas très bien ce que vous voulez dire ici, mais j'ai
l'impression que vous prenez encore le problème à l'envers.
Exact, il me restait effectivement un scrupule à évacuer.
Cette fois c'est clair.
Ceci dit la phrase :
"...préfèrent avoir une horloge unix calée sur TAI"
est ambigüe parce que l'horloge suit effectivement
TAI mais est décalée de 10s.
En fait, quand on fait un choix comme celui-ci, on
ne recherche pas le calage sur telle ou telle
échelle de temps, mais bel et bien le fait d'avoir
une horloge unix uniforme c'est à dire une
succession de valeurs du compteur formant une
suite continue sans sauts ni doublons.
Ok, cappice. Mais donc parmi les 2 zoneinfo/UTC et zoneinfo/right/UTC, s'il y en a une qui se rapporte à TAI (et encore pas exactement mais à TAI+10s) c'est bien zoneinfo/UTC et pas zoneinfo/right/UTC.
Je ne comprends pas très bien ce que vous voulez dire ici, mais j'ai l'impression que vous prenez encore le problème à l'envers.
Exact, il me restait effectivement un scrupule à évacuer.
Cette fois c'est clair.
Ceci dit la phrase :
"...préfèrent avoir une horloge unix calée sur TAI"
est ambigüe parce que l'horloge suit effectivement TAI mais est décalée de 10s.
En fait, quand on fait un choix comme celui-ci, on ne recherche pas le calage sur telle ou telle échelle de temps, mais bel et bien le fait d'avoir une horloge unix uniforme c'est à dire une succession de valeurs du compteur formant une suite continue sans sauts ni doublons.
-- francois meyer
Nicolas George
sebas wrote in message :
C'est le cas dans le pays où j'habite, l'année derniere ils ont decidé de supprimer l'heure d'été. Comment fait-on pour mettre cette base de donnée à jour pour cette region ? (le fichier dans /usr/share/zoneinfo/ est binaire, je ne sais pas comment le modifier). Toutes les entrés que j'ai trouvées sur google expliquent comment changer de tz, mais non comment changer la config d'une region.
La page de man tzfile(5) décrit le format des fichiers de timezone. Ce n'est pas très complexe. Mais la manière normale de faire, c'est de prendre ce qui vient avec la glibc. Si tu indiques quelle timezone c'est, je peux regarder si c'est mis à jour dans la glibc 2.3.2. Si ça n'a pas été fait, il faudra signaler ça aux auteurs.
sebas wrote in message <pan.2004.11.11.23.39.12.949930@nospam.invalid>:
C'est le cas dans le pays où j'habite, l'année derniere ils ont decidé
de supprimer l'heure d'été. Comment fait-on pour mettre cette base de
donnée à jour pour cette region ? (le fichier dans /usr/share/zoneinfo/
est binaire, je ne sais pas comment le modifier). Toutes les entrés que
j'ai trouvées sur google expliquent comment changer de tz, mais non
comment changer la config d'une region.
La page de man tzfile(5) décrit le format des fichiers de timezone. Ce n'est
pas très complexe. Mais la manière normale de faire, c'est de prendre ce qui
vient avec la glibc. Si tu indiques quelle timezone c'est, je peux regarder
si c'est mis à jour dans la glibc 2.3.2. Si ça n'a pas été fait, il faudra
signaler ça aux auteurs.
C'est le cas dans le pays où j'habite, l'année derniere ils ont decidé de supprimer l'heure d'été. Comment fait-on pour mettre cette base de donnée à jour pour cette region ? (le fichier dans /usr/share/zoneinfo/ est binaire, je ne sais pas comment le modifier). Toutes les entrés que j'ai trouvées sur google expliquent comment changer de tz, mais non comment changer la config d'une region.
La page de man tzfile(5) décrit le format des fichiers de timezone. Ce n'est pas très complexe. Mais la manière normale de faire, c'est de prendre ce qui vient avec la glibc. Si tu indiques quelle timezone c'est, je peux regarder si c'est mis à jour dans la glibc 2.3.2. Si ça n'a pas été fait, il faudra signaler ça aux auteurs.
