Daireaux Jean-Baptiste avait écrit le 31/03/2009 :Yannick a écrit :Daireaux Jean-Baptiste avait énoncé :Yannick a écrit :Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de
vérifier si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le
02/03/2009, à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000
-> OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage
en heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000
-> PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947)
donne 20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2
mars' est un fait intangible. Maintenant que je suis le 31 mars, qu'il
me dise que l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le
changement de fuseau horaire sans se préoccuper de la date de
l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2
mars est dans la période heure d'hiver.
J.B.D.
Il s'agit de XP SP3
Mais si DateHeureLocaleVersUTC réagit alors correctement, comment faire
pour tester si un fichier a été modifié ???
Daireaux Jean-Baptiste avait écrit le 31/03/2009 :
Yannick a écrit :
Daireaux Jean-Baptiste avait énoncé :
Yannick a écrit :
Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de
vérifier si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le
02/03/2009, à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000
-> OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage
en heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000
-> PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947)
donne 20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2
mars' est un fait intangible. Maintenant que je suis le 31 mars, qu'il
me dise que l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le
changement de fuseau horaire sans se préoccuper de la date de
l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2
mars est dans la période heure d'hiver.
J.B.D.
Il s'agit de XP SP3
Mais si DateHeureLocaleVersUTC réagit alors correctement, comment faire
pour tester si un fichier a été modifié ???
Daireaux Jean-Baptiste avait écrit le 31/03/2009 :Yannick a écrit :Daireaux Jean-Baptiste avait énoncé :Yannick a écrit :Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de
vérifier si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le
02/03/2009, à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000
-> OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage
en heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000
-> PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947)
donne 20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2
mars' est un fait intangible. Maintenant que je suis le 31 mars, qu'il
me dise que l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le
changement de fuseau horaire sans se préoccuper de la date de
l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2
mars est dans la période heure d'hiver.
J.B.D.
Il s'agit de XP SP3
Mais si DateHeureLocaleVersUTC réagit alors correctement, comment faire
pour tester si un fichier a été modifié ???
Daireaux Jean-Baptiste a écrit :Yannick a écrit :Daireaux Jean-Baptiste avait énoncé :Yannick a écrit :Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier si
un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009, à
7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947) donne
20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2 mars' est
un fait intangible. Maintenant que je suis le 31 mars, qu'il me dise que
l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le changement
de fuseau horaire sans se préoccuper de la date de l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2 mars
est dans la période heure d'hiver.
J.B.D.
Bonjour,
l'explorateur Windows se comporte de la sorte :
fichier A créé le 1 er janvier (heure d'hiver) à 12h00
si on regarde heure de création en heure d'hiver on a 12h00
si on regarde heure de création de ce même fichier en été on a 13h00
2000,XP, Vista en NTSF, avec horloge en UTC.
C'est le comportement attendu d'un local time /utc.
D'où l'intérêt de la fonction "DateHeureLocaleVersUTC" qui devrait afficher
un delta d'une heure en hiver et 2 heure en été.
Cette fonction est OK en WD 10. Je ne peux pas tester en version supérieure
car je ne les ai pas.
Daireaux Jean-Baptiste a écrit :
Yannick a écrit :
Daireaux Jean-Baptiste avait énoncé :
Yannick a écrit :
Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier si
un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009, à
7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947) donne
20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2 mars' est
un fait intangible. Maintenant que je suis le 31 mars, qu'il me dise que
l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le changement
de fuseau horaire sans se préoccuper de la date de l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2 mars
est dans la période heure d'hiver.
J.B.D.
Bonjour,
l'explorateur Windows se comporte de la sorte :
fichier A créé le 1 er janvier (heure d'hiver) à 12h00
si on regarde heure de création en heure d'hiver on a 12h00
si on regarde heure de création de ce même fichier en été on a 13h00
2000,XP, Vista en NTSF, avec horloge en UTC.
C'est le comportement attendu d'un local time /utc.
D'où l'intérêt de la fonction "DateHeureLocaleVersUTC" qui devrait afficher
un delta d'une heure en hiver et 2 heure en été.
Cette fonction est OK en WD 10. Je ne peux pas tester en version supérieure
car je ne les ai pas.
Daireaux Jean-Baptiste a écrit :Yannick a écrit :Daireaux Jean-Baptiste avait énoncé :Yannick a écrit :Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier si
un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009, à
7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947) donne
20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2 mars' est
un fait intangible. Maintenant que je suis le 31 mars, qu'il me dise que
l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le changement
de fuseau horaire sans se préoccuper de la date de l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2 mars
est dans la période heure d'hiver.
J.B.D.
Bonjour,
l'explorateur Windows se comporte de la sorte :
fichier A créé le 1 er janvier (heure d'hiver) à 12h00
si on regarde heure de création en heure d'hiver on a 12h00
si on regarde heure de création de ce même fichier en été on a 13h00
2000,XP, Vista en NTSF, avec horloge en UTC.
C'est le comportement attendu d'un local time /utc.
D'où l'intérêt de la fonction "DateHeureLocaleVersUTC" qui devrait afficher
un delta d'une heure en hiver et 2 heure en été.
Cette fonction est OK en WD 10. Je ne peux pas tester en version supérieure
car je ne les ai pas.
Yannick a écrit :Daireaux Jean-Baptiste avait écrit le 31/03/2009 :Yannick a écrit :Daireaux Jean-Baptiste avait énoncé :Yannick a écrit :Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier
si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009,
à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947) donne
20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2 mars'
est un fait intangible. Maintenant que je suis le 31 mars, qu'il me dise
que l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le
changement de fuseau horaire sans se préoccuper de la date de l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2 mars
est dans la période heure d'hiver.
J.B.D.
Il s'agit de XP SP3
Mais si DateHeureLocaleVersUTC réagit alors correctement, comment faire
pour tester si un fichier a été modifié ???
Tu as raison dans ton raisonnement. Windows affiche le localtime auquel il
ajoute 1 ou 2 heures par rapport à GMT. C'est tout l'intérêt d'utiliser UTC.
Es tu sûre qu'il n'y a pas un paramétrage dans ton bios, qui crée un
problème. Je pense à cela car à une époque lorsque je faisais du dual boot
avec Windows et Linux j'avais des problèmes de ce type.
Yannick a écrit :
Daireaux Jean-Baptiste avait écrit le 31/03/2009 :
Yannick a écrit :
Daireaux Jean-Baptiste avait énoncé :
Yannick a écrit :
Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier
si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009,
à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947) donne
20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2 mars'
est un fait intangible. Maintenant que je suis le 31 mars, qu'il me dise
que l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le
changement de fuseau horaire sans se préoccuper de la date de l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2 mars
est dans la période heure d'hiver.
J.B.D.
Il s'agit de XP SP3
Mais si DateHeureLocaleVersUTC réagit alors correctement, comment faire
pour tester si un fichier a été modifié ???
Tu as raison dans ton raisonnement. Windows affiche le localtime auquel il
ajoute 1 ou 2 heures par rapport à GMT. C'est tout l'intérêt d'utiliser UTC.
Es tu sûre qu'il n'y a pas un paramétrage dans ton bios, qui crée un
problème. Je pense à cela car à une époque lorsque je faisais du dual boot
avec Windows et Linux j'avais des problèmes de ce type.
Yannick a écrit :Daireaux Jean-Baptiste avait écrit le 31/03/2009 :Yannick a écrit :Daireaux Jean-Baptiste avait énoncé :Yannick a écrit :Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier
si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009,
à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947) donne
20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2 mars'
est un fait intangible. Maintenant que je suis le 31 mars, qu'il me dise
que l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le
changement de fuseau horaire sans se préoccuper de la date de l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2 mars
est dans la période heure d'hiver.
J.B.D.
Il s'agit de XP SP3
Mais si DateHeureLocaleVersUTC réagit alors correctement, comment faire
pour tester si un fichier a été modifié ???
Tu as raison dans ton raisonnement. Windows affiche le localtime auquel il
ajoute 1 ou 2 heures par rapport à GMT. C'est tout l'intérêt d'utiliser UTC.
Es tu sûre qu'il n'y a pas un paramétrage dans ton bios, qui crée un
problème. Je pense à cela car à une époque lorsque je faisais du dual boot
avec Windows et Linux j'avais des problèmes de ce type.
Yannick a émis l'idée suivante :Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un fichier
à évolué ?
Comment contourner ce problème ?
Utiliser un Hash...
Yannick a émis l'idée suivante :
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un fichier
à évolué ?
Comment contourner ce problème ?
Utiliser un Hash...
Yannick a émis l'idée suivante :Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un fichier
à évolué ?
Comment contourner ce problème ?
Utiliser un Hash...
Daireaux Jean-Baptiste a écrit :Yannick a écrit :Daireaux Jean-Baptiste avait énoncé :Yannick a écrit :Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de
vérifier si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le
02/03/2009, à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000
-> OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage
en heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000
-> PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947)
donne 20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2
mars' est un fait intangible. Maintenant que je suis le 31 mars, qu'il
me dise que l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le
changement de fuseau horaire sans se préoccuper de la date de
l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2
mars est dans la période heure d'hiver.
J.B.D.
Bonjour,
l'explorateur Windows se comporte de la sorte :
fichier A créé le 1 er janvier (heure d'hiver) à 12h00
si on regarde heure de création en heure d'hiver on a 12h00
si on regarde heure de création de ce même fichier en été on a 13h00
2000,XP, Vista en NTSF, avec horloge en UTC.
C'est le comportement attendu d'un local time /utc.
D'où l'intérêt de la fonction "DateHeureLocaleVersUTC" qui devrait
afficher un delta d'une heure en hiver et 2 heure en été.
Cette fonction est OK en WD 10. Je ne peux pas tester en version
supérieure car je ne les ai pas.
Daireaux Jean-Baptiste a écrit :
Yannick a écrit :
Daireaux Jean-Baptiste avait énoncé :
Yannick a écrit :
Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de
vérifier si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le
02/03/2009, à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000
-> OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage
en heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000
-> PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947)
donne 20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2
mars' est un fait intangible. Maintenant que je suis le 31 mars, qu'il
me dise que l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le
changement de fuseau horaire sans se préoccuper de la date de
l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2
mars est dans la période heure d'hiver.
J.B.D.
Bonjour,
l'explorateur Windows se comporte de la sorte :
fichier A créé le 1 er janvier (heure d'hiver) à 12h00
si on regarde heure de création en heure d'hiver on a 12h00
si on regarde heure de création de ce même fichier en été on a 13h00
2000,XP, Vista en NTSF, avec horloge en UTC.
C'est le comportement attendu d'un local time /utc.
D'où l'intérêt de la fonction "DateHeureLocaleVersUTC" qui devrait
afficher un delta d'une heure en hiver et 2 heure en été.
Cette fonction est OK en WD 10. Je ne peux pas tester en version
supérieure car je ne les ai pas.
Daireaux Jean-Baptiste a écrit :Yannick a écrit :Daireaux Jean-Baptiste avait énoncé :Yannick a écrit :Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de
vérifier si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le
02/03/2009, à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000
-> OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage
en heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000
-> PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Je pense que c'est fdateheure qui déconne dans ton exemple.
20090302081947 appartient à la période de l'heure d'hiver donc sa
transformation en heure UTC donne +1h.
fdateheure n'a pas a changer l'heure.
J.B.D.
Pas d'accord
fdateheure renvoie bien la même date/heure qu'on peut voir sous
l'explorateur windows.
Ce qui ne va pas, c'est que DateHeureLocaleVersUTC(20090302081947)
donne 20090302071947000, alors qu'on est maintenant en heure d'été !
Personne n'utilise donc DateHeureLocaleVersUTC afin de tester si un
fichier à évolué ?
Comment contourner ce problème ?
Alors l'explorateur windows a aussi un bug ! l'heure n'a pas à changer !
Si ton fichier a été modifié le 2 mars à 7h19. il n'y a pas de raison
logique à modifier le fait. 'Le fichier a été modifié à 7h19 le 2
mars' est un fait intangible. Maintenant que je suis le 31 mars, qu'il
me dise que l'évènement a eu lieu le 2 mars à 8h19 est une grave erreur.
Je pense que windows renvoie l'heure à laquelle il a appliqué le
changement de fuseau horaire sans se préoccuper de la date de
l'évènement.
Quel windows au fait ?
Je trouve encore une fois que 'DateHeureLocaleVersUTC' fonctionne
correctement : le 2 mars 7h19 devient en UTC le 2 mars 06h19 car le 2
mars est dans la période heure d'hiver.
J.B.D.
Bonjour,
l'explorateur Windows se comporte de la sorte :
fichier A créé le 1 er janvier (heure d'hiver) à 12h00
si on regarde heure de création en heure d'hiver on a 12h00
si on regarde heure de création de ce même fichier en été on a 13h00
2000,XP, Vista en NTSF, avec horloge en UTC.
C'est le comportement attendu d'un local time /utc.
D'où l'intérêt de la fonction "DateHeureLocaleVersUTC" qui devrait
afficher un delta d'une heure en hiver et 2 heure en été.
Cette fonction est OK en WD 10. Je ne peux pas tester en version
supérieure car je ne les ai pas.
Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier
si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009,
à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier
si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009,
à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier
si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009,
à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
C'est vrai que meme qd on liste le contenu, certain fichier change d'heure
en meme temps qu'on change d'heure été/hiver
Ca vient de la conversion :
Heure fichier enregistré en UTC
Heure fichier affichée en heure locale mais basée sur l'heure du PC au lieu
d'utiliser l'heure du fichier.
Je pense que ton problème vient du fait que tu utilise fdate qui renvoie
l'heure locale .
Pour vérifier :
Crée un fichier avec ton pc en heure d'été
test1: Appelle fdateheure avec l'heure de ton PC en été
test2: Appelle fdateheure avec l'heure de ton PC en hiver
utilise plutot l'api GetFileTime qui renvoi directement l'heure utc du
fichier.
Pour info, le mot d'excuse de microsoft:
FileTimeToLocalFileTime() Adjusts for Daylight Saving Time
Last reviewed: September 25, 1995
Article ID: Q128126
The information in this article applies to:
a.. Microsoft Win32 Application Programming Interface (API) included
with:
- Microsoft Windows NT version 3.5
SUMMARY
Under NTFS, the API GetFileTime() returns the create time, last access
time, and last write time for the specified file. The times returned in the
FILETIME structures are in Universal Coordinated Time (UTC). This is also
the time that NTFS uses. You can use FileTimeToLocalFileTime() to convert a
file time to a local time. However, if you automatically adjust for Daylight
Saving Time, FileTimeToLocalFileTime() will adjust for Daylight Saving Time
based on whether the current date should be adjusted for Daylight Saving
Time, not based on whether the date represented by the FILETIME structure
should be adjusted.
The behavior in this situation is different under FAT, but may be
changed to match the behavior under NTFS in a future version of Windows NT.
"Yannick" a écrit dans le message de
news:49d0b4db$0$15331$Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier
si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009,
à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
C'est vrai que meme qd on liste le contenu, certain fichier change d'heure
en meme temps qu'on change d'heure été/hiver
Ca vient de la conversion :
Heure fichier enregistré en UTC
Heure fichier affichée en heure locale mais basée sur l'heure du PC au lieu
d'utiliser l'heure du fichier.
Je pense que ton problème vient du fait que tu utilise fdate qui renvoie
l'heure locale .
Pour vérifier :
Crée un fichier avec ton pc en heure d'été
test1: Appelle fdateheure avec l'heure de ton PC en été
test2: Appelle fdateheure avec l'heure de ton PC en hiver
utilise plutot l'api GetFileTime qui renvoi directement l'heure utc du
fichier.
Pour info, le mot d'excuse de microsoft:
FileTimeToLocalFileTime() Adjusts for Daylight Saving Time
Last reviewed: September 25, 1995
Article ID: Q128126
The information in this article applies to:
a.. Microsoft Win32 Application Programming Interface (API) included
with:
- Microsoft Windows NT version 3.5
SUMMARY
Under NTFS, the API GetFileTime() returns the create time, last access
time, and last write time for the specified file. The times returned in the
FILETIME structures are in Universal Coordinated Time (UTC). This is also
the time that NTFS uses. You can use FileTimeToLocalFileTime() to convert a
file time to a local time. However, if you automatically adjust for Daylight
Saving Time, FileTimeToLocalFileTime() will adjust for Daylight Saving Time
based on whether the current date should be adjusted for Daylight Saving
Time, not based on whether the date represented by the FILETIME structure
should be adjusted.
The behavior in this situation is different under FAT, but may be
changed to match the behavior under NTFS in a future version of Windows NT.
"Yannick" <a@a.fr> a écrit dans le message de
news:49d0b4db$0$15331$426a74cc@news.free.fr...
Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier
si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009,
à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
C'est vrai que meme qd on liste le contenu, certain fichier change d'heure
en meme temps qu'on change d'heure été/hiver
Ca vient de la conversion :
Heure fichier enregistré en UTC
Heure fichier affichée en heure locale mais basée sur l'heure du PC au lieu
d'utiliser l'heure du fichier.
Je pense que ton problème vient du fait que tu utilise fdate qui renvoie
l'heure locale .
Pour vérifier :
Crée un fichier avec ton pc en heure d'été
test1: Appelle fdateheure avec l'heure de ton PC en été
test2: Appelle fdateheure avec l'heure de ton PC en hiver
utilise plutot l'api GetFileTime qui renvoi directement l'heure utc du
fichier.
Pour info, le mot d'excuse de microsoft:
FileTimeToLocalFileTime() Adjusts for Daylight Saving Time
Last reviewed: September 25, 1995
Article ID: Q128126
The information in this article applies to:
a.. Microsoft Win32 Application Programming Interface (API) included
with:
- Microsoft Windows NT version 3.5
SUMMARY
Under NTFS, the API GetFileTime() returns the create time, last access
time, and last write time for the specified file. The times returned in the
FILETIME structures are in Universal Coordinated Time (UTC). This is also
the time that NTFS uses. You can use FileTimeToLocalFileTime() to convert a
file time to a local time. However, if you automatically adjust for Daylight
Saving Time, FileTimeToLocalFileTime() will adjust for Daylight Saving Time
based on whether the current date should be adjusted for Daylight Saving
Time, not based on whether the date represented by the FILETIME structure
should be adjusted.
The behavior in this situation is different under FAT, but may be
changed to match the behavior under NTFS in a future version of Windows NT.
"Yannick" a écrit dans le message de
news:49d0b4db$0$15331$Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier
si un fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la
fonction DateHeureLocaleVersUTC), change au passage à l'heure d'été
uniquement pour les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009,
à 7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 ->
OK (1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en
heure d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Yannick a écrit :Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier si un
fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la fonction
DateHeureLocaleVersUTC), change au passage à l'heure d'été uniquement pour
les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009, à
7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 -> OK
(1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en heure
d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Bonjour,
la fonction je la comprends comme toi. En heure d'été tu devrais avoir -2
heures.
Je viens de tester sous WD10, tu as bien 2 heures de décalage.
Yannick a écrit :
Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier si un
fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la fonction
DateHeureLocaleVersUTC), change au passage à l'heure d'été uniquement pour
les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009, à
7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 -> OK
(1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en heure
d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Bonjour,
la fonction je la comprends comme toi. En heure d'été tu devrais avoir -2
heures.
Je viens de tester sous WD10, tu as bien 2 heures de décalage.
Yannick a écrit :Bonjour
Je rencontre un problème à l'utilisation de la fonction
DateHeureLocaleVersUTC (je me sert de cette fonction afin de vérifier si un
fichier a été modifié).
Le problème est que la date/heure UTC d'un fichier (donnée par la fonction
DateHeureLocaleVersUTC), change au passage à l'heure d'été uniquement pour
les fichiers modifiés prendant la période d'hiver !!!
Concrêtement
Le fichier en question a été modifié, la dernière fois, le 02/03/2009, à
7H19Mn47 (en heure d'hiver)
Jusqu'à samedi :
fDateHeure donnait 20090302071947 -> OK
DateHeureLocaleVersUTC(20090302071947) donnait -> 20090302061947000 -> OK
(1 heure de décallage)
Le problème est à partir de dimanche (passage en heure d'été) :
fDateHeure donne 20090302081947 -> OK (1 heure de plus car passage en heure
d'été)
DateHeureLocaleVersUTC(20090302081947) donne -> 20090302071947000 ->
PROBLEME !!!!!!
Y aurtait-il quelque chose que je fais mal dans l'utilisation
DateHeureLocaleVersUTC ?
Merci pour vos réponses
Yannick
Bonjour,
la fonction je la comprends comme toi. En heure d'été tu devrais avoir -2
heures.
Je viens de tester sous WD10, tu as bien 2 heures de décalage.