As I mentioned recently, I think I finally know why this test fails and I think I know what we'll have to do about it, but I thought I would run it by folks first. Let's back up for a moment, though, and look at what the test is doing. We are testing the "vmsish 'time'" pragma, which the docs say, well, here's what they say:
"vmsish time"
This makes all times relative to the local time zone, instead of
the default of Universal Time (a.k.a Greenwich Mean Time, or GMT).
Specifically, test #25 does stat() on a file to get its modification
time. It does this both with and without "vmsish 'time'" in effect
and compares the difference. Normally the difference should be
whatever is in the logical name SYS$TIMEZONE_DIFFERENTIAL, i.e., the
number of seconds the local time is offset from UTC.
The problem that arises is that the correct differential for the
revision time of a file is whatever the UTC offset was at the time
the file was revised, not whatever the UTC offset is now. Both
"vmsish 'time'" and the CRTL's stat() correctly use the former, but
the test uses the latter.
Let me illustrate. The test uses itself as the object of the stat()
call, and the current RDT for [.lib]vmsish.t is 13-JUN-2003
02:41:00.00. In my neck of the woods, daylight savings was in effect
last June, and the timezone differential was -18000. Both stat() and
"vmsish 'time'" parse the timezone rules for my timezone and use that
differential. Right now, however, daylight savings is not in effect
and the timezone offset is -21600, and that's what the test uses to
generate its expected value for comparison. So the comparison value
will be off by an hour and the test will fail because we're using the
wrong value for comparison.
This explains a number of bizarre behaviors that we've seen as long
as we've noticed problems with this test. If I made an unrelated
change to the test script, that would update its revision date and
the test would start succeeding. Ditto if I unpacked my Perl archive
in a way that updated timestamps on the files in it. In these cases
the test will keep succeeding until the next daylight savings switch,
at which point it will start to fail. That's why it succeeded when
5.8.2 was released but failed before 5.8.3 was released without any
changes to the test itself or the underlying code. Also, folks in
timezones who don't use daylight savings and have the same timezone
differential year-round would see the test succeed, and we could
never figure out why it failed in some timezones and succeeded in
others.
So, in sum, it's a test bug, and we can either:
1.) Make the test parse the timezone rules so it knows which offset
to apply to the results of stat(). Ouch. That would be difficult to
get right and I don't think I'm up to it.
2.) Make the test do a stat() on something whose timezone
differential we can know with certainty. I'm thinking of just
creating a temporary file. The current offset will always be correct
for that. This doesn't test the full capabilities of "vmsish
'time'", but we couldn't do that without doing #1.
Does this make sense to everyone? Anyone? A patch implementing #2
is attached.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
%
Description: application/applefile
vmsish_t_25.patch
Description: Binary data
