Geoffrey Young wrote:
Or is it safe to just ignore the problem? Any real users out there will
presumably have a ctime that matches the current system time, because
they'll probably have extracted the mod_perl archive only just prior to
building & testing it.
Otherwise I'm happy for the test to be skipped, so long as there is a
brief comment explaining the reason.
my own thought is this...
if we have verified that perl is reporting the correct answer (we've
looked at the file on the filesystem and know perl gets it right
according to us humans) then the fix really should be in APR - APR is
supposed to exist so we can forget about these cross-platform issues and
focus on the "real" stuff.
Unfortunately, Perl arguably doesn't get it right, which is the reason
for the existence of my Win32::UTCFileTime module ;-)
There is a difficulty in deciding what is "right", though. The real
problem is MS's crap CRT library: its stat() function returns
definitively wrong file times across DST season boundaries, which leaves
anything wrapping that stat() function with a dilemma:
- Should the wrapper try to be portable, ironing out the idiosyncracies
of the various systems on which it is built, so as to always yield the
same answer? (This is understandably the approach that APR has taken,
that being largely the point of it.)
- Or should the wrapper be a thinner, less interventionist layer that
seeks only to expose the underlying system behaviour to some new
interface? (This is the approach that Perl has taken, simply exposing
the CRT library function, with all its quirks and foibles, to Perl.)
So just don't go waiting around for APR to be "fixed", because I doubt
very much that its authors consider it to be broken.
------------------------------------------------
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.
