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