473,231 Members | 1,572 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,231 software developers and data experts.

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ø
Nov 8 '05 #1
5 3289
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
Nov 8 '05 #2
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
Nov 8 '05 #3
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
Nov 8 '05 #4
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ø
Nov 8 '05 #5
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
Nov 8 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

9
by: Amir Dekel | last post by:
Hi everyone, I have two problems: 1. How can I keep my changes in sys.path after closing the interpreter? 2. os.path.expanduser("~") always gives me "C:\\" instead of my homepath. I have...
6
by: kimes | last post by:
I've just started digging into how python works.. I found that other mudules are clearly declared like one file per a module.. But the only os.path doesn't have their own file.. ye I know is...
8
by: Glenn A. Harlan | last post by:
Why am I receiving the below error when calling - Path.GetTempFileName() The directory name is invalid. Description: An unhandled exception occurred during the execution of the current web...
2
by: Rob Cowie | last post by:
Hi, Given a string representing the path to a file, what is the best way to get at the filename? Does the OS module provide a function to parse the path? or is it acceptable to split the string...
1
by: Jody Gelowitz | last post by:
We are having an issue in that when trying to read a file that is on Server2 from Server1 (through our ASP.NET project), we receive the error: Access to the path "\\Server2\MyShare\MyFile.tif" is...
0
by: Jody Gelowitz | last post by:
VS2005 Standard Edition WinXP Pro SP2 I have setup a Web project under: http://localhost/myproject/ and have received a "Failed to map the path '/MyProject/App_GlobalResources'." error...
7
by: siggi | last post by:
Hi all, when I do >>>sys.path in IDLE (winXP), i get a horrendously long list of paths, paths I may have used during a lot of trials and errors. How can I clean up sys.path? I mean, trim it of...
3
by: junchi.tang | last post by:
Hi, I am new to python and are tryint to write a simple program delete log files that are older than 30 days. So I used os.path.getmtime(filepath) and compare it with a date but it does not...
7
by: Daniel | last post by:
Hello, I'm writing some unit tests for my python software which uses packages. Here is the basic structure: mypackage __init__.py module1 __init__.py mod1.py
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.