Re: 8.3 vs HEAD difference in Interval output?

On Thu, Oct 09, 2008 at 11:50:17AM -0700, Ron Mayer wrote:
> Kevin Grittner wrote:
>>>>> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Even more surprising is the behavior for interval(1) here:
>> [.... some context with nonsurprising examples removed ...]
>> ccdev=# select '1 year 2 mons 3 days 04:05:06.64321'::interval(1);
>> interval
>> ----------------------------------
>> 1 year 2 mons 3 days 04:05:06.60
>> (1 row)
>> That trailing zero should be considered a bug.
>
> Is there a consensus that we don't want that trailing zero?
> I notice that datetime.c's "TrimTrailingZeros(char *str)" has
> the comment:
> /* chop off trailing zeros... but leave at least 2 fractional digits */
> that suggests that the trailing zero was intentional, but I
> can't find any reasons why 2 fractional disgits were left.
>
> The same function's also used for timestamps, so if we remove that
> trailing zero in both places we'll see some regression differences
> where we get
> ! | Mon Feb 10 17:32:01.5 1997 PST | 1997 | 7 | 1
> instead of
> ! | Mon Feb 10 17:32:01.50 1997 PST | 1997 | 7 | 1
>
> IMHO we don't want the extra zero for timestamps either.
>
There is a difference between the result 0.6 and 0.60 in rounding.
The first is accurate +-0.05 and the second is +-0.005. Certainly,
it does not seem unreasonable that machines can calulate intervals
to the nearest 100th of a second. What is not clear to me is how the
decision to stop at the 2nd decimal digit was reached. If timestamps
are accurate to 1/100th, intervals should be returned to that level
of accuracy as well. Trailing digits definitely have meaning.

My 2 cents,
Ken

>
> If people agree I'll fold it into the patch dealing with
> the other interval rounding eccentricities I have.
>
> Tom Lane wrote:
>> Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
>>> [some other interval rounding example]
>> I don't much like the forced rounding to two digits here, but changing
>> that doesn't seem like material for back-patching. Are you going to
>> fix that up while working on your other patches?
>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>