Re: [BUGS] BUG #1927: incorrect timestamp returned

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> I think it'd probably be better to just fix the rounding during display.
>
> > If we do that, should we remove some the existing JROUND calls in the
> > code? I think we have to do this consistently, at least.
>
> Yeah, I was looking at that --- I think most if not all of the existing
> JROUND calls ought to go away. Will try to work up a full patch over
> the weekend.

OK

> > Also, I don't see how rounding is going to fix the problem that the
> > value is actually _rounded_ at different stages, meaning when you are
> > doing the output you don't know what came in, as outlined by my
> > timestamp_in data.
>
> I think the solution is that timestamp_out needs to decide how many
> fractional digits it wants to display, and then round off the input
> accordingly, *before* it breaks the input down into y/m/d/h/m/s fields.
> This "60.00" business is happening because the rounding is done only on
> the seconds-and-fractional-seconds field.

Well, the testing showed that the one with the most 9's was actually
rounded up to a whole number by timestamp_in, meaning we never have a
chance to adjust it in timestamp_out. I am assuming you will be able to
round the middle test value up to a whole number in timestamp_out so the
60 number will disappear.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073