Ron Mayer <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> We could try to do the same in the float case, but I'm a bit worried >> about finding ourselves showing "1234567.799999" where it should be >> "1234567.8".
> If I understand the code right fsec should mostly be values > between -1 and 1 anyway, because even in the floating point > case seconds are carried in the tm->tm_sec part. The problem is that that's a decomposed representation. In the stored form, there's a floating-point seconds field that includes hours, minutes, seconds, and fractional seconds, and therefore large values of the H/M/S fields degrade the accuracy of the fraction part. Here's an example (testing in 8.3, since HEAD defaults to integer): regression=# select '1234567890 hours 0.123 sec'::interval; interval ------------------------- 1234567890:00:00.123047 (1 row) Since there's a (somewhat arbitrary) limitation of the hours to 2^31, this is close to the worst possible case. (Hm, maybe someone actually did the math and decided that 2 fractional digits were the most they could promise given that? No, because this code dates from a time when we included days in the same field too ... back then there might have been no accuracy at all in the fraction part.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers