Re: uh-oh, buildfarm all red - Mailing list pgsql-hackers

From Tom Lane
Subject Re: uh-oh, buildfarm all red
Date
Msg-id 26412.1144025539@sss.pgh.pa.us
Whole thread Raw
In response to Re: uh-oh, buildfarm all red  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Looks like someone has re-introduced a test case that fails on the day
>> of a US daylight-savings transition.

> Hmm ... this test has actually been in there for ages.

>   SELECT CAST(CAST(date 'today' + time with time zone '01:30'
>     + interval '02:01' AS time with time zone) AS time) AS "03:31:00";

Yeah, that was what I found out when I actually looked into fixing it.
I'm not sure why we failed to identify this query as an issue when we
"fixed" the DST-boundary problems before.

> Looks like it failed last April but not last October.

Right, because during a step-back the 01:30 time would be ambiguous,
and would be resolved as standard time, leading to the result still
being 03:31 standard time.  In the step-forward case, the step occurs
after 01:30 and results in "two hours later" being 04:31 daylight time.

Maybe we missed this because we only tested the autumn case when we
changed the regression tests to avoid the problems.  I don't remember.

> Anyway ... yes, let's remove it.

What I did instead was to move the test time forward a bit so that it
wouldn't be subject to insertion of an hour at DST boundaries:
 SELECT CAST(CAST(date 'today' + time with time zone '05:30'   + interval '02:01' AS time with time zone) AS time) AS
"07:31:00";
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: Suggestion: Which Binary?
Next
From: "Marc G. Fournier"
Date:
Subject: Re: semaphore usage "port based"?