Re: Bad interval conversion?

On Tue, Aug 18, 2009 at 12:07, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Throwing overflow errors doesn't seem very nice either, especially not
> for values that worked just fine before 8.4.

I just checked both 8.3.7 and 8.2.13 give:
# select '4817191.623 ms'::interval;
interval
------------------
-00:35:47.483648
(1 row)

> Seems like a proper fix would involve doing some modulo arithmetic to be
> sure that we add the integral seconds to the seconds field and only a
> fraction to the fsec field.

Ok I looked around at the other fsec assignments in adt/ and did not
see any that were not treating them as fractional correctly. This
seems to be the only case. Anywho is the below more what you
expected? (I decided to do it for the floating point case as well...)

With this patch I get (it also passes a make check):
# select '4817191.623 ms'::interval;
interval
-----------------
01:20:17.191623

*** a/src/backend/utils/adt/datetime.c
--- b/src/backend/utils/adt/datetime.c
***************
*** 2986,2991 **** DecodeInterval(char **field, int *ftype, int nf, int range,
--- 2986,2994 ----
break;

case DTK_MILLISEC:
+ tm->tm_sec += val / 1000;
+ val = val % 1000;
+
#ifdef HAVE_INT64_TIMESTAMP
*fsec += rint((val +
fval) * 1000);
#else