Bruce Momjian wrote:
>
> At this point, I think we have everything resolved for 6.1.
>
> The regression tests look good.
Yes, but a small issue...
The horology "expected" patches Bruce applied just recently to fix the
timezone behavior for 3 rows of results from calculating
datetime-minus-timespan cause my regression test to fail, as you would
expect.
But looking into it further, I found the following behavior:
If you set TZ="PST8PDT" on my machine, you get Bruce's results.
If you set TZ="PST8PDT7,M04.01.00,M10.05.03" on my machine, you get my
original regression results!
Conclusions:
1) The public-domain localtime package used by _many_ systems has
signed-math trouble for timezones but only when interpreting a full TZ.
2) The PST8PDT timezone database supplied on many systems has the
correct information.
3) Bruce was not following the directions for the regression test :))
(or his USE_POSIX_TIME but !HAVE_INT_TIMEZONE machine does not exhibit
the bug, a more likely scenerio but it's more fun to needle Bruce...)
OK, so here is the question:
Should we assume that every installation environment has a PST8PDT
timezone database installed, or should we have the regression tests use
the full-length TZ assignment which produces a few bad-but-consistant
values on many/most platforms??
I'd be inclined to go with the bad-but-consistant solution, because a
failed regression test on a system without the problem is obviously
correct by inspection; that is not true the other way around.
I'll go either way, and can patch either the regression results or the
instructions to be self-consistant.
We should _especially_ hear from anyone who might have a problem with
the PST8PDT timezone database (e.g. Easter Europe or southern hemisphere
where the default rules are likely to be different).
- Tom
------------------------------
