os.path.getmtime on winXP

Discussion in 'Python' started by =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?=, Nov 8, 2005.

  1. [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ø
     
    =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?=, Nov 8, 2005
    #1
    1. Advertising

  2. On Tue, 08 Nov 2005 07:57:44 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= <> 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: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
     
    Bengt Richter, Nov 8, 2005
    #2
    1. Advertising

  3. 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
     
    =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?=, Nov 8, 2005
    #3
  4. On Tue, 08 Nov 2005 10:49:56 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= <> 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
     
    Bengt Richter, Nov 8, 2005
    #4
  5. 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ø
     
    =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?=, Nov 8, 2005
    #5
  6. On Tue, 08 Nov 2005 13:33:12 +0100, =?ISO-8859-1?Q?Jorg_R=F8dsj=F8?= <> 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
     
    Bengt Richter, Nov 8, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Qvx
    Replies:
    3
    Views:
    381
    Nick Coghlan
    Jan 29, 2005
  2. Josef Dalcolmo
    Replies:
    1
    Views:
    1,792
    John Machin
    May 3, 2007
  3. Replies:
    3
    Views:
    512
    Anthony Greene
    Sep 20, 2007
  4. mynthon
    Replies:
    5
    Views:
    2,043
    krowey
    Feb 9, 2013
  5. Tim Johnson
    Replies:
    0
    Views:
    262
    Tim Johnson
    Sep 14, 2011
Loading...

Share This Page