Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals |
Дата | |
Msg-id | 200510261449.j9QEnCb14461@candle.pha.pa.us обсуждение исходный текст |
Ответы |
Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals
|
Список | pgsql-hackers |
[ bugs list removed, hackers added.] Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I saw a lot of disussion because I forgot to specify that my tests were > > for EST5EDT, but what about the use of interval_justify_hours() in > > timestamp_mi(). Is this something we want to change? > > It's too late to mess with it for 8.1, but see my previous message > proposing a set of TODO items for future work. Yes, it is late, but I am worried about adding an interface change that we will later revert in 8.2. In 8.0.X I see the query returning the '25 hour' answer: SELECT('2005-10-29 13:22:00-04'::timestamptz +('2005-10-30 13:22:00-05'::timestamptz - '2005-10-29 13:22:00-04'::timestamptz))at time zone 'EST'; timezone--------------------- 2005-10-30 13:22:00(1 row) In current CVS the top query returns '14:22:00'. Do we change this for 8.1, then change it back in 8.2? That seems bad to me. Actually, 8.0.X returns '1 day, 1 hour' for the subtraction, which we treat in 8.0.X as '25 hours':SELECT ('2005-10-30 13:22:00-05'::timestamptz - '2005-10-29 13:22:00-04'::timestamptz); ?column?---------------- 1 day 01:00:00(1 row) In 8.0.X, because we didn't have a 'days' field, we could treat '1 day 1 hour' as always '25 hours', and could display the results as days/hours. If we remove interval_justify_hours(), then we are always going to display timestamp subtraction in hours (not days), e.g. '6422 hours' (yea, ugly) unless they manually call interval_justify_hours(). Keep in mind that the addition of the interval_justify_hours() did generate some regression test changes, so removing interval_justify_hours() might just take the results back to what we had in 8.0. My point is that regression changes caused by its removal might not be a good guide to determining compatibility with 8.0.X. I guess my point is that we are changing 8.0.X behavior so we better be sure it is now the way we want it to remain. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: