stat/mtime on Windows changes with daylight saving

Discussion in 'Perl Misc' started by Oliver Betz, Jul 14, 2005.

  1. Oliver Betz

    Oliver Betz Guest

    Hi,

    is this a Windows or ActivePerl (I'm using 5.8.2) bug?

    (stat())->mtime reports 3600 more or less if the file is in the other
    daylight savings state than the system time.

    For example, the stat->mtime results if Windows is in timezone UTC
    without daylight savings (Casablanca...):

    1970-01-01 10:00:00Z -> 36000 (as expected)
    1970-07-01 10:00:00Z -> 15674400 (as expected)

    In a Timezone with daylight savings, system date in winter, I get
    36000 and 15670800 (one hour less) for the same files.

    In a Timezone with daylight savings, system date in summer, I get
    39600 (one hour more) and 15674400 for the same files.

    All tests done on NTFS drives. No difference whether it's a local file
    or via network. Same results with newer dates, but I liked the smaller
    mtime numbers for the demonstration.

    Who tweaks the file time, Perl or Windows?

    mtime should be constant, shouldn't it?

    Oliver
    --
    Oliver Betz, Munich
     
    Oliver Betz, Jul 14, 2005
    #1
    1. Advertising

  2. Oliver Betz

    Oliver Betz Guest

    I wrote:

    >is this a Windows or ActivePerl (I'm using 5.8.2) bug?


    seemingly both. It's a bug in the MS C stat() function, has been filed
    already 2004-01 at ActiveState
    http://bugs.activestate.com/show_bug.cgi?id=29239 and (likely) can be
    circumvented by using Win32::UTCFileTime from CPAN (which contains a
    comprehensive explanation).

    Cygwin Perl doesn't need this patch.

    I wonder why ActiveState doesn't solve this.

    Oliver
    --
    Oliver Betz, Munich
     
    Oliver Betz, Jul 14, 2005
    #2
    1. Advertising

  3. Oliver Betz

    Sisyphus Guest

    "Oliver Betz" <>

    >
    > I wonder why ActiveState doesn't solve this.
    >


    You would think that the corrections offered by Win32-UTCFileTime could be
    incorporated into the perl source. Why that hasn't happened is a question
    that should probably be raised with the perl porters (p5p) rather than
    ActiveState.

    Cheers,
    Rob
     
    Sisyphus, Jul 15, 2005
    #3
  4. Oliver Betz

    Oliver Betz Guest

    "Sisyphus" <> wrote:

    >> I wonder why ActiveState doesn't solve this.

    >
    >You would think that the corrections offered by Win32-UTCFileTime could be
    >incorporated into the perl source. Why that hasn't happened is a question


    One could also use a C compiler without the stat() bug as far as I
    understand.

    >that should probably be raised with the perl porters (p5p) rather than
    >ActiveState.


    Maybe. I thought it is an ActiveState issue because Cygwin's Perl
    works as expected here.

    What is ActiveState's contribution?

    Oliver
    --
    Oliver Betz, Munich
     
    Oliver Betz, Jul 15, 2005
    #4
  5. Oliver Betz

    Sisyphus Guest

    "Oliver Betz" <> wrote in message
    news:...
    > "Sisyphus" <> wrote:
    >
    > >> I wonder why ActiveState doesn't solve this.

    > >
    > >You would think that the corrections offered by Win32-UTCFileTime could

    be
    > >incorporated into the perl source. Why that hasn't happened is a question

    >
    > One could also use a C compiler without the stat() bug as far as I
    > understand.


    Yes - that's my understanding, too. I gather it's a MSVC++ bug, not a Win32
    bug, and that a perl compiled on Win32 with, say, MinGW(which is the
    compiler I generally use) or Borland won't suffer the problem.

    >
    > >that should probably be raised with the perl porters (p5p) rather than
    > >ActiveState.

    >
    > Maybe. I thought it is an ActiveState issue because Cygwin's Perl
    > works as expected here.
    >
    > What is ActiveState's contribution?
    >


    Afaik, they pretty much just take the cpan source, compile it with VC6, and
    make the binaries available to the public. Of course, they also contribute
    to that cpan source - but I don't regard it as their responsibility to fix
    this specific problem. I would think, however, that the perl porters as a
    whole would be keen to see this issue resolved - which is why I mentioned
    the possibility of contacting them. (It's quite possible that they are
    already aware of this, btw. And it's also possible that there are good
    reasons that no fix has yet been incorporated into the perl source. This
    problem apparently doesn't affect FAT systems - and I don't know if/how that
    impacts upon this issue.)

    The author of Win32::UTCFileTime might have some advice on how to proceed if
    you want to advance the cause. I wouldn't be at all surprised if he has
    previously raised it with the porters. (In fact, I'm a little surprised that
    he didn't submit patches to the perl source, instead choosing to write a
    workaround - which strengthens my suspicion that this problem cannot easily
    be fixed.)

    Cheers,
    Rob
     
    Sisyphus, Jul 15, 2005
    #5
    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. Steven T. Hatton
    Replies:
    3
    Views:
    9,746
    Pete Becker
    Jun 2, 2005
  2. Patrick Useldinger

    os.stat('<filename>')[stat.ST_INO] on Windows

    Patrick Useldinger, Feb 27, 2005, in forum: Python
    Replies:
    6
    Views:
    1,210
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
    Mar 3, 2005
  3. Replies:
    2
    Views:
    316
    John O'Conner
    Jan 3, 2007
  4. Magesh
    Replies:
    3
    Views:
    462
    Gordon Burditt
    Oct 5, 2007
  5. Rolf Krüger
    Replies:
    2
    Views:
    636
    Ian Collins
    Mar 12, 2008
Loading...

Share This Page