Re: Have I found an interval arithmetic bug?

From: Zhihong Yu <zyu(at)yugabyte(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Bryn Llewellyn <bryn(at)yugabyte(dot)com>, Tom Lane PostgreSQL <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, John W Higgins <wishdev(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Have I found an interval arithmetic bug?
Date: 2021-07-22 22:17:52
Message-ID: CALNJ-vQMtXJ325fjrXBXKkpN+jHQqYJssLjHeBaXNO5ENP4Odw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Jul 22, 2021 at 2:59 PM Zhihong Yu <zyu(at)yugabyte(dot)com> wrote:

>
>
> 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
>
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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marcin Barczynski 2021-07-23 06:09:18 Re: Why does VACUUM FULL pg_class sometimes wait for ShareLock on another transaction after getting AccessExclusiveLock on pg_class?
Previous Message Zhihong Yu 2021-07-22 21:59:42 Re: Have I found an interval arithmetic bug?

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2021-07-22 22:32:18 Re: Slightly improve initdb --sync-only option's help message
Previous Message Zhihong Yu 2021-07-22 21:59:42 Re: Have I found an interval arithmetic bug?