Re: Have I found an interval arithmetic bug? - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: Have I found an interval arithmetic bug?
Date
Msg-id CALNJ-vQMtXJ325fjrXBXKkpN+jHQqYJssLjHeBaXNO5ENP4Odw@mail.gmail.com
Whole thread Raw
In response to Re: Have I found an interval arithmetic bug?  (Zhihong Yu <zyu@yugabyte.com>)
Responses Re: Have I found an interval arithmetic bug?  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers


On Thu, Jul 22, 2021 at 2:59 PM Zhihong Yu <zyu@yugabyte.com> wrote:


On Wed, Jul 21, 2021 at 6:43 PM Bruce Momjian <bruce@momjian.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@momjian.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 
Hi,
I guess the reason for current patch was that year to months conversion is accurate.
On the new test:

+SELECT INTERVAL '1.16 months 01:00:00' AS "One mon 5 days one hour";

0.16 * 31 = 4.96 < 5

I wonder why 5 days were chosen in the test output.

pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: Have I found an interval arithmetic bug?
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Slightly improve initdb --sync-only option's help message