Dennis, > It doesn't discuss it. According to the spec a timestamp with time zone is > a UTC value + a HH:MM offset from GMT. And intervals in the spec is either > a year-month value or a day-time value. One can only compare year-month > values with each other and day-time values with each other. So they avoid > the problem of the how many days is a month by not allowing it.
That's not what Tom and I were talking about. The issue is that the spec defines Days/Weeks as being an agglomeration of hours and not an atomic entity like Months/Years are. This leads to some wierd and calendar-breaking behavior when combined with DST, for example: template1=> select '2004-10-09 10:00 PDT'::TIMESTAMPTZ + '45 days'::INTERVAL template1-> ; ?column? ------------------------ 2004-11-23 09:00:00-08 (1 row) Because of the DST shift, you get an hour shift which is most decidely not anything real human beings would expect from a calendar. The answer is to try-partition INTERVAL values, as: Hour/Minute/Second/ms Day/Week Month/Year However, this could be considered to break the spec; certainly Thomas thought it did. My defense is that the SQL committee made some mistakes, and interval is a big one. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])