Re: Have I found an interval arithmetic bug?

On Wed, Jul 21, 2021 at 6:43 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Wed, Jul 21, 2021 at 06:39:26PM -0700, Bryn Llewellyn wrote:
> > Your statement
> >
> >
> > “months-to-days conversion is almost always an approximation, while
> the
> > days to seconds conversion is almost always accurate.”
> >
> >
> > is misleading. Any conversion like these (and also the “spill up”
> conversions
> > that the justify_hours(), justify_days(), and justify_interval() built-in
> > functions bring) are semantically dangerous because of the different
> rules for
> > adding a pure months, a pure days, or a pure seconds interval to a
> timestamptz
> > value.
>
> We are trying to get the most reasonable output for fractional values
> --- I stand by my statements.
>
> > Unless you avoid mixed interval values, then it’s so hard (even though
> it is
> > possible) to predict the outcomes of interval arithmetic. Rather, all
> you get
> > is emergent behavior that I fail to see can be relied upon in
> deliberately
> > designed application code. Here’s a telling example:
>
> The point is that we will get unusual values, so we should do the best
> we can.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
> EDB https://enterprisedb.com
>
> If only the physical world exists, free will is an illusion.
>
> Hi,

- tm->tm_mon += (fval * MONTHS_PER_YEAR);
+ tm->tm_mon += rint(fval * MONTHS_PER_YEAR);

Should the handling for year use the same check as that for month ?

- AdjustFractDays(fval, tm, fsec, DAYS_PER_MONTH);
+ /* round to a full month? */
+ if (rint(fval * DAYS_PER_MONTH) == DAYS_PER_MONTH)

Cheers