Regression test horology failure
Attached are regression diffs for 7.4.10, compiled from source on RHEL 3 U6
(gcc 3.2.3 20030502, glibc-2.3.2-95.37) using:
make distclean
./configure '--with-perl' '--prefix=/usr/local/postgresql-7.4.10'
make && make install && make check
The tests fail for PST/PDT in 2034.
Looking at the buildfarm there is no other RHEL 3 system building the 7.4
branch at the moment. The same is true for 7.3.12 and 7.4.7 by the way.
Is this a local problem in my glibc/tz libraries? I am not really worried
because I will upgrade to 8.1 shortly, but understanding the problem would
be a good thing.
Tom, you are building 7.3 for RedHat, do you see any similar regression
failures?
Best Regrads,
Michael Paesold
Attachments:
regression.difftext/plain; format=flowed; name=regression.diff; reply-type=originalDownload
*** ./expected/horology.out Thu Sep 25 08:58:06 2003
--- ./results/horology.out Tue Dec 13 15:25:07 2005
***************
*** 1755,1765 ****
| Tue Dec 31 17:32:01 1996 PST | @ 34 years | Tue Dec 31 17:32:01 2030 PST
| Fri Dec 31 17:32:01 1999 PST | @ 34 years | Sat Dec 31 17:32:01 2033 PST
| Sat Jan 01 17:32:01 2000 PST | @ 34 years | Sun Jan 01 17:32:01 2034 PST
! | Wed Mar 15 02:14:05 2000 PST | @ 34 years | Wed Mar 15 02:14:05 2034 PST
! | Wed Mar 15 03:14:04 2000 PST | @ 34 years | Wed Mar 15 03:14:04 2034 PST
! | Wed Mar 15 08:14:01 2000 PST | @ 34 years | Wed Mar 15 08:14:01 2034 PST
! | Wed Mar 15 12:14:03 2000 PST | @ 34 years | Wed Mar 15 12:14:03 2034 PST
! | Wed Mar 15 13:14:02 2000 PST | @ 34 years | Wed Mar 15 13:14:02 2034 PST
| Sun Dec 31 17:32:01 2000 PST | @ 34 years | Sun Dec 31 17:32:01 2034 PST
| Mon Jan 01 17:32:01 2001 PST | @ 34 years | Mon Jan 01 17:32:01 2035 PST
| Sat Sep 22 18:19:20 2001 PDT | @ 34 years | Sat Sep 22 18:19:20 2035 PDT
--- 1755,1765 ----
| Tue Dec 31 17:32:01 1996 PST | @ 34 years | Tue Dec 31 17:32:01 2030 PST
| Fri Dec 31 17:32:01 1999 PST | @ 34 years | Sat Dec 31 17:32:01 2033 PST
| Sat Jan 01 17:32:01 2000 PST | @ 34 years | Sun Jan 01 17:32:01 2034 PST
! | Wed Mar 15 02:14:05 2000 PST | @ 34 years | Wed Mar 15 02:14:05 2034 PDT
! | Wed Mar 15 03:14:04 2000 PST | @ 34 years | Wed Mar 15 03:14:04 2034 PDT
! | Wed Mar 15 08:14:01 2000 PST | @ 34 years | Wed Mar 15 08:14:01 2034 PDT
! | Wed Mar 15 12:14:03 2000 PST | @ 34 years | Wed Mar 15 12:14:03 2034 PDT
! | Wed Mar 15 13:14:02 2000 PST | @ 34 years | Wed Mar 15 13:14:02 2034 PDT
| Sun Dec 31 17:32:01 2000 PST | @ 34 years | Sun Dec 31 17:32:01 2034 PST
| Mon Jan 01 17:32:01 2001 PST | @ 34 years | Mon Jan 01 17:32:01 2035 PST
| Sat Sep 22 18:19:20 2001 PDT | @ 34 years | Sat Sep 22 18:19:20 2035 PDT
======================================================================
"Michael Paesold" <mpaesold@gmx.at> writes:
The tests fail for PST/PDT in 2034.
This probably indicates that you've got TZ data reflecting the new US
DST rules. We have not updated the pre-8.0 regression test results
to deal with that.
regards, tom lane
Tom Lane schrieb:
"Michael Paesold" <mpaesold@gmx.at> writes:
The tests fail for PST/PDT in 2034.
This probably indicates that you've got TZ data reflecting the new US
DST rules. We have not updated the pre-8.0 regression test results
to deal with that.
You're right as far as I can tell. 8.1 has the expected output.
The failing tests are different instances of this basic example:
Expected:
Wed Mar 15 08:14:01 2000 PST + 34 years = Wed Mar 15 08:14:01 2034 PST
Here (and PostgreSQL >= 8.x):
Wed Mar 15 08:14:01 2000 PST + 34 years = Wed Mar 15 08:14:01 2034 PDT
Still, I don't understand why March 15th should be day light saving
time. But hey, I don't live in the PST8PDT time zone. ;-)
Thanks for your answer.
Best Regards,
Michael Paesold