On Thu, Jul 22, 2021 at 2:59 PM Zhihong Yu <z...@yugabyte.com> wrote:
> > > On Wed, Jul 21, 2021 at 6:43 PM Bruce Momjian <br...@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 <br...@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.
