perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <>
Subject Re: [mp2] finfo->ctime on Win32
Date Wed, 31 May 2006 15:06:46 GMT
Randy Kobes wrote:
> Hi Steve, and all,
>    With the svn mp2 sources on Win32, and with either
> Apache/2.0 or Apache/2.2, I'm getting a couple of
> failures on t/(apr|apr-ext)/finfo.t with the finfo->ctime
> tests. The failures looked like
>    # testing : $finfo->ctime()
>    # expected: 1135891825
>    # received: 1135888225
> and so differ by 3600. Steve, I know that you've
> encountered this general type of problem before
> (in the context of Win32::UTCFileTime, and related
> to time zones and daylight savings time) - do you
> see a similar failure? I'm thinking it might be an
> idea to just skip the ctime tests on Win32, unless
> someone knows what the root cause of the problem is.
> Thanks.

The problem that I've encountered before is where MS's CRT stat() 
function returns the wrong time (by one hour) when the file time 
(access, creation or modification) being retrieved lies in the opposite 
DST seasons to the current system time.

That is why the tests do a utime() call on Win32.  I originally 
had a problem with the mtime, but I haven't seen that problem recur see 
we introduced that utime() call:

I once also had a failure with atime, which Geoffrey pointed out could 
be due to the worrying noises that MSDN makes about the ftLastAccessTime 
member in the structure populated by GetFileInformationByHandle() always 
being set to midnight.  We eventually decided that skipping the atime 
test was best on Win32:

However, MSDN doesn't give the same warnings about ctime, so AFAICT it 
should work:

What filesystem are you running these tests on?  What timezone / DST 
season is your system in?  Are the file times on your being 
correctly reset by the utime() call?

Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential
and intended for the addressee(s) only. If you have received this message in error or there
are any problems, please notify the sender immediately. The unauthorized use, disclosure,
copying or alteration of this message is strictly forbidden. Note that any views or opinions
presented in this email are solely those of the author and do not necessarily represent those
of Radan Computational Ltd. The recipient(s) of this message should check it and any attached
files for viruses: Radan Computational will accept no liability for any damage caused by any
virus transmitted by this email.
View raw message