Re: fixes for date_part micro/millisecond precision - Mailing list pgsql-patches

From Tom Lane
Subject Re: fixes for date_part micro/millisecond precision
Date
Msg-id 29599.1006633947@sss.pgh.pa.us
Whole thread Raw
In response to Re: fixes for date_part micro/millisecond precision  (Brent Verner <brent@rcfile.org>)
Responses Re: fixes for date_part micro/millisecond precision  (Brent Verner <brent@rcfile.org>)
List pgsql-patches
Brent Verner <brent@rcfile.org> writes:
> ... if I insert a timestamp of
> '2001-1-1 11:11:11.12341234-05' I /really/ want to get back '12341234'
> when  I ask for the microseconds that I stored,

You cannot expect to get that back exactly, because *the precision is
not there* (and yes, the term here is precision not accuracy).  Right
now (late 2001) we have about seven digits of precision to the right
of the decimal point in a timestamp.  As we get further away from the
2000-01-01 origin, precision will drop; it'll be six digits or less
by 2010.  The further you go from 2000 in either direction, the worse
the precision.

This is an inherent property of float arithmetic and can't be papered
over with display hacks, at least not without losing more than you gain.

> Is there a better place to 'force' the accuracy of the fractional
> second part that would be less prone to introduce other problems?

You cannot force accuracy that isn't there.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: fixes for date_part micro/millisecond precision
Next
From: Brent Verner
Date:
Subject: Re: fixes for date_part micro/millisecond precision