Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > os.path.getmtime on winXP

Reply
Thread Tools

os.path.getmtime on winXP

 
 
=?ISO-8859-1?Q?Jorg_R=F8dsj=F8?=
Guest
Posts: n/a
 
      11-08-2005
[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ø
 
Reply With Quote
 
 
 
 
Bengt Richter
Guest
Posts: n/a
 
      11-08-2005
On Tue, 08 Nov 2005 07:57:44 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
=?ISO-8859-1?Q?Jorg_R=F8dsj=F8?=
Guest
Posts: n/a
 
      11-08-2005
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
 
Reply With Quote
 
Bengt Richter
Guest
Posts: n/a
 
      11-08-2005
On Tue, 08 Nov 2005 10:49:56 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= <(E-Mail Removed)> 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
 
Reply With Quote
 
=?ISO-8859-1?Q?Jorg_R=F8dsj=F8?=
Guest
Posts: n/a
 
      11-08-2005
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ø
 
Reply With Quote
 
Bengt Richter
Guest
Posts: n/a
 
      11-08-2005
On Tue, 08 Nov 2005 13:33:12 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Slipstreaming winxp 64 sp2 into Winxp 64 Kue2 Windows 64bit 10 03-17-2007 12:13 AM
Is 64-bit WinXP faster than 32-bit WinXP? Man-wai Chang Windows 64bit 10 04-23-2006 01:25 PM
WinXP 64 .mp3 summary change to look like WinXP 32? Manquala Windows 64bit 4 01-15-2006 04:01 AM
USB 2.0 in non SP1 WinXP unholy Software 30 11-04-2005 06:36 AM
Problems connecting to Internet with a Dlink 614+ and WinXP Bubster Wireless Networking 3 06-29-2004 04:37 PM



Advertisments