Re: [HACKERS] datetime regression test fails at daylight savings transitions

> Whoops. Looks like "'1 day'::timespan" is treated as "24 hours",
> not as "the same local time next day". Twice a year (if you observe
> DST) there is a difference.

Sure. But timespan doesn't know anything about date context. What you
are really asking about is the behavior with math across two date/time
data types.

> It's debatable whether this is a bug in the date/time datatypes,
> or just sloppy coding of the regression test. It probably oughta be
> documented somewhere, either way. Also, whichever way we decide the
> above expressions ought to be handled, the docs ought to explain
> how to get the other functionality.

Hmm. So the debate won't cover whether Tom got it right, just how wrong
he got it, eh? :)

The docs actually mention the distinction between "qualitative time"
(years and months) and "quantitative time" (days, hours, minutes,
seconds) when discussing the "timespan" data type.

You will find that months and years do behave the way you would expect,
since they are stored as "qualitative" times. So adding a month to a
time at the end of the previous month will try to line things up:

tgl=> select '1998-01-31'::datetime + '1 month'::timespan;
----------------------------
Sat Feb 28 00:00:00 1998 GMT

The real lesson to me is to never put out a "last call" to ask people to
run the regression tests on the day of a daylight savings time
transition...

- Tom