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
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.
Hello hackers,
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 off by one microsecond. Looking at
