Tom and Tom,
> This isn't a bug per the existing definition of INTERVAL. '250 days'
> is
> defined as '250*24 hours', exactly, no more no less. When you move
> across a DST boundary you get behavior like the above.
> I've opined several times that interval should account for three
> separate units: months, days, and seconds. But our time-meister
> Tom Lockhart doesn't seem to have taken any interest in the idea.
I beg to differ with Tom L. Even if there were justification for the
addition of an hour to a calculation involving only days, which there
is not, there are two bugs with the existing behavior:
1. You do not lose an hour with the end of DST, you just gain one with
the beginning of it (until you wraparound a whole year, which is really
confusing), which is inconsistent;
2. Even if you justify gaining or losing an hour through DST in a
'+days' operation, changing the TIMEZONE is a bizarre and confusing way
to do it. I don't fly to Colorado on April 7th!
While this needs to be fixed eventually, I need a quick workaround; is
there a way to "turn off" DST behavior in PostgreSQL?
Further, it seems that the whole "Interval" section of Postgres,
possibly one of our greatest strengths as a database, has languished in
the realm of inconsistent behavior due to lack of interest. Is there
anything I can do without learning C?
-Josh Berkus
