Date: Mon, 12 Apr 2021 19:22:37 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Bryn Llewellyn <bryn@yugabyte.com>
Cc: Zhihong Yu <zyu@yugabyte.com>, Justin Pryzby <pryzby@telsasoft.com>,
	Isaac Morland <isaac.morland@gmail.com>,
	John W Higgins <wishdev@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Tom Lane PostgreSQL <tgl@sss.pgh.pa.us>
Subject: Re: Have I found an interval arithmetic bug?
Message-ID: <20210412232237.GA4231@momjian.us>
References: <E34DA978-0C0E-4F43-97CD-278FA0C228E5@yugabyte.com>
 <20210403022126.GG29126@momjian.us>
 <20210405163310.GP6592@telsasoft.com>
 <20210405180158.GB12179@momjian.us>
 <20210408172444.GC6909@momjian.us>
 <CALNJ-vR9s8zjGkUrxqLbK5GMS8Rn-o=dxb56gNSaWCHUKQZAvQ@mail.gmail.com>
 <CALNJ-vQE-W9K8b_XicbeR6CEkzUsA=CqarkwTLjudYTBpH90uw@mail.gmail.com>
 <CALNJ-vQkNfeM--i_L9XSpXsP_sj=UYFnAtF+u2ZhGUSe0PW6Cw@mail.gmail.com>
 <20210412161842.GA22319@momjian.us>
 <8707105F-C45D-4ACB-8F71-51CE5BED58A5@yugabyte.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8707105F-C45D-4ACB-8F71-51CE5BED58A5@yugabyte.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/20210412232237.GA4231%40momjian.us>
Precedence: bulk

On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote:
> I showed you all this example a long time ago:
> 
> select (
>     '
>       3.853467 years
>     '::interval
>   )::text as i;
> 
> This behavior is the same in the env. of Bruce’s patch as in unpatched PG 13.2. This is the result.
> 
> 3 years 10 mons
> 
> Notice that "3.853467 years" is "3 years" plus "10.241604 months". This explains the "10 mons" in the result. But the 0.241604 months remainder did not spill down into days.
> 
> Can anybody defend this quirk? An extension of this example with a real number of month in the user input is correspondingly yet more quirky. The rules can be written down. But they’re too tortuos to allow an ordinary mortal confidently to design code that relies on them.
> 
> (I was unable to find any rule statement that lets the user predict this in the doc. But maybe that’s because of my feeble searching skills.)
> 
> If there is no defense (and I cannot imagine one) might Bruce’s patch normalize this too to follow this rule:
> 
> — convert 'y years m months' to the real number y*12 + m.
> 
> — record truc( y*12 + m) in the "months" field of the internal representation
> 
> — flow the remainder down to days (but no further)
> 
> After all, you've bitten the bullet now and changed the behavior. This means that the semantics of some extant applications will change. So... in for a penny, in for a pound?

The docs now say:

     Field values can have fractional parts;  for example, <literal>'1.5
     weeks'</literal> or <literal>'01:02:03.45'</literal>.  The fractional
-->  parts are used to compute appropriate values for the next lower-order
     internal fields (months, days, seconds).

meaning fractional years flows to the next lower internal unit, months,
and no further.  Fractional months would flow to days.  The idea of not
flowing past the next lower-order internal field is that the
approximations between units are not precise enough to flow accurately.

With my patch, the output is now:

	SELECT INTERVAL '3 years 10.241604 months';
	        interval
	------------------------
	 3 years 10 mons 7 days

It used to flow to seconds.

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

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