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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
