Thread: Regression Testing on REL6_5_PATCHES

I have hit an unexpected error in regression testing the REL6_5_PATCHES branch
in preparing for 6.5.3.  For the first time, a test other than float or
geometry failed -- with a weird result.  Datetime failed.  Here is the section
of regression.diffs for datetime:
----------------------------
*** expected/datetime.out    Wed Apr 14 22:19:01 1999
--- results/datetime.out    Mon Nov  1 22:40:45 1999
***************
*** 1,7 **** QUERY: SELECT ('today'::datetime = ('yesterday'::datetime + '1 day'::timespan)) as "True"; True ----
! t    (1 row)  QUERY: SELECT ('today'::datetime = ('tomorrow'::datetime - '1 day'::timespan)) as "True";
--- 1,7 ---- QUERY: SELECT ('today'::datetime = ('yesterday'::datetime + '1 day'::timespan)) as "True"; True ----
! f    (1 row)  QUERY: SELECT ('today'::datetime = ('tomorrow'::datetime - '1 day'::timespan)) as "True";
***************
*** 13,19 **** QUERY: SELECT ('tomorrow'::datetime = ('yesterday'::datetime + '2 days'::timespan)) as "True"; True
----
! t    (1 row)  QUERY: SELECT ('current'::datetime = 'now'::datetime) as "True";
--- 13,19 ---- QUERY: SELECT ('tomorrow'::datetime = ('yesterday'::datetime + '2 days'::timespan)) as "True"; True
----
! f    (1 row)  QUERY: SELECT ('current'::datetime = 'now'::datetime) as "True";
***************
*** 69,75 **** QUERY: SELECT count(*) AS one FROM DATETIME_TBL WHERE d1 = 'today'::datetime - '1 day'::timespan; one
---
!   1 (1 row)  QUERY: SELECT count(*) AS one FROM DATETIME_TBL WHERE d1 = 'now'::datetime;
--- 69,75 ---- QUERY: SELECT count(*) AS one FROM DATETIME_TBL WHERE d1 = 'today'::datetime - '1 day'::timespan; one
---
!   0 (1 row)  QUERY: SELECT count(*) AS one FROM DATETIME_TBL WHERE d1 = 'now'::datetime;

-------------------------------
Misc also failed -- but that was due to the pgaccess relations from my pgaccess
testing.

System: RedHat Linux 6.1 -- kernel 2.2.12 w/ glibc 2.1.2.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:
> I have hit an unexpected error in regression testing the
> REL6_5_PATCHES branch in preparing for 6.5.3.  For the first time, a
> test other than float or geometry failed -- with a weird result.
> Datetime failed.

Yup, it's the biannual daylight-savings-time transition weirdness.
If you look closely, all those tests assume that today midnight to
tomorrow midnight is 24 hours.  Guess what: at this time of year it
ain't.  In another day or so the results will be back to normal, at
least in the US of A.  We'll likely see another gripe or two from
overseas before the DST-switch season is over.

I've been around this project for a year and a half now, and we've
heard complaints like this at each of the three DST transitions that
I remember.  (I sent in some alarmed reports myself, first time I
saw it.)  I've tried to interest Thomas in DST-proofing the regress
tests, but he doesn't seem to think it's worth fixing.

There should be something about this in the "expected failures"
section of the regress test docs, but right at the moment I don't
see anything there.
        regards, tom lane

Tom Lane wrote:
> 
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > I have hit an unexpected error in regression testing the
> > REL6_5_PATCHES branch in preparing for 6.5.3.  For the first time, a
> > test other than float or geometry failed -- with a weird result.
> > Datetime failed.

> There should be something about this in the "expected failures"
> section of the regress test docs, but right at the moment I don't
> see anything there.

Now it's my turn to feel much better.  The tests that failed were float8
(which is the NaN glibc weirdness we already know about -- I forget the
specifics, but it was tracked down -- although, I had thought that would
be fixed for 6.5.3, but I guess I was mistaken), datetime (which you've
explained), geometry (which failed due to a floating point roundoff
error), and misc (which didn't like the pgaccess preferences tables
being in there).

I'm glad it was something that simple.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

> I've been around this project for a year and a half now, and we've
> heard complaints like this at each of the three DST transitions that
> I remember.  (I sent in some alarmed reports myself, first time I
> saw it.)  I've tried to interest Thomas in DST-proofing the regress
> tests, but he doesn't seem to think it's worth fixing.

Hmm. I'm probably pretty unimaginative, but when the test is
 select datetime 'tomorrow' - datetime 'today';

it is pretty hard to make this "DST proof". The alternative was to not
test this case at all, which I definitely was *not* interested in.

Ideas? At least with the test as-is, I get nice fan mail twice a year
;)
                    - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California