Re: uh-oh, buildfarm all red
От | Tom Lane |
---|---|
Тема | Re: uh-oh, buildfarm all red |
Дата | |
Msg-id | 26412.1144025539@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: uh-oh, buildfarm all red (Andrew Dunstan <andrew@dunslane.net>) |
Список | 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 по дате отправления: