Re: os.path.getmtime on winXP
On Tue, 08 Nov 2005 07:57:44 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= [EMAIL
PROTECTED] 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.py')))
'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:38595 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: os.path.getmtime on winXP
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: os.path.getmtime on winXP
On Tue, 08 Nov 2005 10:49:56 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= [EMAIL PROTECTED] 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_file) 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: os.path.getmtime on winXP
Bengt Richter wrote:
By 'getmtime' you mean os.path.getmtime(fer_shure_or_absolute_path_to_file)
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ø
--
http://mail.python.org/mailman/listinfo/python-list
Re: os.path.getmtime on winXP
On Tue, 08 Nov 2005 13:33:12 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= [EMAIL
PROTECTED] wrote:
Bengt Richter wrote:
By 'getmtime' you mean os.path.getmtime(fer_shure_or_absolute_path_to_file)
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
--
http://mail.python.org/mailman/listinfo/python-list
os.path.getmtime on winXP
[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ø -- http://mail.python.org/mailman/listinfo/python-list
