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
