os.path.getmtime on winXP

[Jorg Rødsjø]

[sorry to those reading twice, but I just realised that I had posted
this after mucking about with the date on my machine to try to figure
this out -- so the message probably went into last months messages for
most people including me.]

Hi

I'm trying to use os.path.getmtime to check if a file has been modified.
My OS is WinXP. The problem is, that when the os changes from/to
daylight savings time, the result is suddenly off by 3600 seconds ie.
one hour, even if the file remains the same.

I've tried using win32file.GetFileTime, and it reports a consistent
number, regardless of DST.

What is happening here? My first thought is that getmtime should measure
'raw' time, and not be concerned with DST, and thus give me the same
result no matter the date on the machine I call it. Is the module broken
in some way, or am I just missing something here?

regards
Jorg Rødsjø

[Bengt Richter]

On Tue, 08 Nov 2005 07:57:44 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= <jo**@neoplex.org> wrote:

[sorry to those reading twice, but I just realised that I had posted
this after mucking about with the date on my machine to try to figure
this out -- so the message probably went into last months messages for
most people including me.]

Hi

I'm trying to use os.path.getmtime to check if a file has been modified.
My OS is WinXP. The problem is, that when the os changes from/to
daylight savings time, the result is suddenly off by 3600 seconds ie.
one hour, even if the file remains the same.
Well, if the file hasn't been modified, the file time should be wrt
a constant epoch, so you must be observing a DST-corrected conversion
of that number, but you don't show what you are using.
E.g. you can convert with time.localtime or time.gmtime, and format the
result any way you want with time.strftime(...)

time.strftime('%Y-%m-%d %H:%M:%S', time.localtime(os.path.getmtime('wc.py'))) '2003-09-10 14:38:57' time.strftime('%Y-%m-%d %H:%M:%S', time.gmtime(os.path.getmtime('wc.py'))) '2003-09-10 21:38:57'

Which comes from os.path.getmtime('wc.py') 1063229937

And default localtime formatting is time.ctime(os.path.getmtime('wc.py')) 'Wed Sep 10 14:38:57 2003'

which is time.asctime(time.localtime(os.path.getmtime('wc.p y'))) 'Wed Sep 10 14:38:57 2003'

the GMT version of which is time.asctime(time.gmtime(os.path.getmtime('wc.py') )) 'Wed Sep 10 21:38:57 2003'

reflecting os.system('dir wc.py')

Volume in drive C is System
Volume Serial Number is 14CF-C4B9

Directory of c:\pywk\clp

03-09-10 14:38 595 wc.py


I've tried using win32file.GetFileTime, and it reports a consistent
number, regardless of DST.

What is happening here? My first thought is that getmtime should measure
'raw' time, and not be concerned with DST, and thus give me the same
result no matter the date on the machine I call it. Is the module broken
in some way, or am I just missing something here?

How did you format the number you got from os.path.getmtime?
You might want to try some of the above.

If you actually created/modified files just before and after the DST change
and saw an extra hour difference instead of the time between the two actions,
then maybe I'd look into whether the OS has some perverse option to use local DST
time to record in the file stat info, but that's hard to believe. More likely someone
is messing with with raw file time setting, like touch. Don't have it handy to see
what DST assumptions it makes if any.

Regards,
Bengt Richter

[Jorg Rødsjø]

Bengt Richter wrote:

How did you format the number you got from os.path.getmtime?
I'm not doing any formating at all. I am just looking at the numbers of
seconds since epoch. Which is what makes it so strange.
You might want to try some of the above.
I'll do that. At the moment I'm looking at the difference between
localtime and gmtime to see if my computer is in dst. If it is not, I
just add 3600 seconds to the result from os.path.getmtime -- which then
should give consistent results.
If you actually created/modified files just before and after the DST change
and saw an extra hour difference instead of the time between the two actions,
then maybe I'd look into whether the OS has some perverse option to use local DST
time to record in the file stat info, but that's hard to believe. More likely someone
is messing with with raw file time setting, like touch. Don't have it handy to see
what DST assumptions it makes if any.

The files I am testing with have not been modified for a long time.
Windows reports the modified date as being the same, no matter what I do
(both through the gui, and through win32file). And they all show the
same strange 3600 sec difference with/without dst when I call getmtime
on them.

-jorg

[Bengt Richter]

On Tue, 08 Nov 2005 10:49:56 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= <jo**@neoplex.org> wrote:

Bengt Richter wrote:

How did you format the number you got from os.path.getmtime?
I'm not doing any formating at all. I am just looking at the numbers of
seconds since epoch. Which is what makes it so strange.

You might want to try some of the above.

I'll do that. At the moment I'm looking at the difference between
localtime and gmtime to see if my computer is in dst. If it is not, I
just add 3600 seconds to the result from os.path.getmtime -- which then
should give consistent results.

the time module should know how to do that for you, unless something is fubar.

see time.timz
import time
help(time)

If you actually created/modified files just before and after the DST change
and saw an extra hour difference instead of the time between the two actions,
then maybe I'd look into whether the OS has some perverse option to use local DST
time to record in the file stat info, but that's hard to believe. More likely someone
is messing with with raw file time setting, like touch. Don't have it handy to see
what DST assumptions it makes if any.

The files I am testing with have not been modified for a long time.
Windows reports the modified date as being the same, no matter what I do
(both through the gui, and through win32file). And they all show the
same strange 3600 sec difference with/without dst when I call getmtime
on them.

By 'getmtime' you mean os.path.getmtime(fer_shure_or_absolute_path_to_fil e) right?
Doesn't that get you an integer number of seconds? What GUI or win32file is showing you
that integer so you see a 3600 sec difference? Or how are you seeing it?

Could you paste an example of this difference from an example on your screen?
I don't think I am understanding ;-) ... urk, it's late ;-/

Regards,
Bengt Richter

[Jorg Rødsjø]

Bengt Richter wrote:

By 'getmtime' you mean os.path.getmtime(fer_shure_or_absolute_path_to_fil e) right?
Doesn't that get you an integer number of seconds? What GUI or win32file is showing you
that integer so you see a 3600 sec difference? Or how are you seeing it?

Could you paste an example of this difference from an example on your screen?
I don't think I am understanding ;-) ... urk, it's late ;-/

(Btw: thanks for the interest.)

Step by step example:
[I do of cource not modify the foo.py-file at any time during the testing.]

With the system-date set to the 8th of november(no dst) I run the following
os.path.getmtime('spam.py'), and get 1045578240 as the result.

With the system-date set to the 8th of october(dst) I run the following
os.path.getmtime('spam.py'), and get 1045581840 as the result.

This is what boggles my mind. These numbers should be the same -- right?
Not offsett by 3600.

On both dates, calling Windows win32file.GetFileTime (from the Python
Win32 Extensions) gives me the time 02/18/03 14:24:00 -- i.e. the same
both before and after setting the time.

I have not looked at the source to either win32file.GetFileTime or
os.path.getmtime, but I should think that they should both call the same
underlying Windows-function.

I hope this makes it more clear. Any idea why this happens?

regards
Jorg Rødsjø

[Bengt Richter]

On Tue, 08 Nov 2005 13:33:12 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= <jo**@neoplex.org> wrote:

Bengt Richter wrote:

By 'getmtime' you mean os.path.getmtime(fer_shure_or_absolute_path_to_fil e) right?
Doesn't that get you an integer number of seconds? What GUI or win32file is showing you
that integer so you see a 3600 sec difference? Or how are you seeing it?

Could you paste an example of this difference from an example on your screen?
I don't think I am understanding ;-) ... urk, it's late ;-/

(Btw: thanks for the interest.)

Step by step example:
[I do of cource not modify the foo.py-file at any time during the testing.]

With the system-date set to the 8th of november(no dst) I run the following
os.path.getmtime('spam.py'), and get 1045578240 as the result.

With the system-date set to the 8th of october(dst) I run the following
os.path.getmtime('spam.py'), and get 1045581840 as the result.

This is what boggles my mind. These numbers should be the same -- right?
Not offsett by 3600.

On both dates, calling Windows win32file.GetFileTime (from the Python
Win32 Extensions) gives me the time 02/18/03 14:24:00 -- i.e. the same
both before and after setting the time.

I have not looked at the source to either win32file.GetFileTime or
os.path.getmtime, but I should think that they should both call the same
underlying Windows-function.

I hope this makes it more clear. Any idea why this happens?

Ok, now it's clear, thanks ;-)

Well, it seems like a bug, on the face of it.
os.path (at least when it is alias for ntpath.py) just calls os.stat:
"""
def getmtime(filename):
"""Return the last modification time of a file, reported by os.stat()"""
return os.stat(filename).st_mtime
"""
So maybe the next step is to check os.stat to verify it does the same, and then
get to the bottom of how os.stat is is really implemented.

Regards,
Bengt Richter