Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Petr Fedorov <petr.fedorov@phystech.edu>
Cc: pgsql-bugs@postgresql.org
Date: 2019-11-30T15:21:01Z
Lists: pgsql-bugs, pgsql-hackers
Petr Fedorov <petr.fedorov@phystech.edu> writes: > select extract(epoch from '2001-09-09 01:46:40.000021'::timestamp) > returns 1000000000.00002 - 1 microsecond is truncated. > Obviously, it is due to the fact that extract epoch returns double > precision which in turn has 15 decimal digits precision. I can't get very excited about this. However, it might be worth noting that v12 and HEAD print "1000000000.000021" as expected, thanks to the Ryu float output code. You can get that from older branches as well if you set extra_float_digits = 1. By my arithmetic, IEEE float8 ought to be able to represent microseconds accurately out to about 285 years either way from the 1970 epoch, so for practical purposes it'll be fine for a long time. regards, tom lane
Commits
-
Fix inconsistent equalfuncs.c behavior for FuncCall.funcformat.
- a65e9f3f1405 14.0 landed
-
Doc: fix discussion of how to get real Julian Dates.
- f6171e6843f0 9.6.22 landed
- c93f8f3b8d3b 14.0 landed
- 824df1cccb74 12.7 landed
- 7cd542023056 11.12 landed
- 7bbcfb4d584d 13.3 landed
- 56e234b6aff9 10.17 landed
-
Doc: document EXTRACT(JULIAN ...), improve Julian Date explanation.
- ec5bab9217cd 13.3 landed
- b391db4943dc 9.6.22 landed
- b230618ce875 12.7 landed
- 79a5928ebcb7 14.0 landed
- 64d617de3c59 10.17 landed
- 4b610547c27a 11.12 landed
-
Change return type of EXTRACT to numeric
- a2da77cdb466 14.0 landed
-
Improve our ability to regurgitate SQL-syntax function calls.
- 40c24bfef925 14.0 landed
-
Add more tests for EXTRACT of date type
- 540612fa469e 14.0 landed
-
Expose internal function for converting int64 to numeric
- 0aa8f764088e 14.0 landed
-
Change floating-point output format for improved performance.
- 02ddd499322a 12.0 cited