From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: uh-oh, buildfarm all red |
Date: | 2006-04-03 00:52:19 |
Message-ID: | 26412.1144025539@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Scholes | 2006-04-03 00:53:34 | WAL Bypass for indexes |
Previous Message | Robert Treat | 2006-04-03 00:47:04 | Re: Suggestion: Which Binary? |