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

From Bruce Momjian
Subject Re: Have I found an interval arithmetic bug?
Date
Msg-id 20210403010229.GE29126@momjian.us
Whole thread Raw
In response to Re: Have I found an interval arithmetic bug?  (Bryn Llewellyn <bryn@yugabyte.com>)
Responses Re: Have I found an interval arithmetic bug?  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Apr  2, 2021 at 05:50:59PM -0700, Bryn Llewellyn wrote:
> are the user’s parameterization. All are real numbers. Because non-integral
> values for years, months, days, hours, and minutes are allowed when you specify
> a value using the ::interval typecast, my reference doc must state the rules. I
> would have struggled to express these rules in prose—especially given the use
> both of trunc() and floor(). I would have struggled more to explain what
> requirements these rules meet.

The fundamental issue is that while months, days, and seconds are
consistent in their own units, when you have to cross from one unit to
another, it is by definition imprecise, since the interval is not tied
to a specific date, with its own days-of-the-month and leap days and
daylight savings time changes.  It feels like it is going to be
imprecise no matter what we do.

Adding to this is the fact that interval values are stored in C 'struct
tm' defined in libc's ctime(), where months are integers, so carrying
around non-integer month values until we get a final result would add a
lot of complexity, and complexity to a system that is by definition
imprecise, which doesn't seem worth it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.




pgsql-hackers by date:

Previous
From: Kazutaka Onishi
Date:
Subject: Re: TRUNCATE on foreign table
Next
From: Peter Geoghegan
Date:
Subject: Re: Using COPY FREEZE in pgbench