stat/mtime on Windows changes with daylight saving

[Oliver Betz]

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]

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

 

[Sisyphus]

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

 

[Oliver Betz]

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

 

[Sisyphus]

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.

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