Tom,
You are of course right that you cannot add precision that was not there to
begin with. My patch does nothing for input values that cannot be
represented accurately to begin with. However, that was not my main point.
The idea with the calculation is this: When you remove the integral/seconds
Hi Tom, and others,
Thanks for the insightful feedback. You are right, the patch does suffer
from overflow (and other possible issues when I think about it). Using
rint(), as you suggest, helps in my original example case, but there are
still cases when the output is not what you would expect. For
=?UTF-8?Q?Erik_Nordstr=C3=B6m?= writes:
> Thanks for the insightful feedback. You are right, the patch does suffer
> from overflow (and other possible issues when I think about it). Using
> rint(), as you suggest, helps in my original example case, but there are
> still cases when the output is no
I wrote:
> I wonder if we could make things better just by using rint() rather than
> a naive cast-to-integer. The cast will truncate not round, and I think
> that might be what's mostly biting you. Does this help for you?
> #ifdef HAVE_INT64_TIMESTAMP
> - result = seconds * USECS_PE
=?UTF-8?Q?Erik_Nordstr=C3=B6m?= writes:
> I stumbled upon a precision issue with the to_timestamp() function that
> causes it to return unexpected timestamp values. For instance, the query
> SELECT to_timestamp(1486480176.236538) returns the timestamp "2017-02-07
> 16:09:36.236537+01", which is of
