Date: Mon, 5 Apr 2021 14:37:54 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Bryn Llewellyn <bryn@yugabyte.com>, Zhihong Yu <zyu@yugabyte.com>,
	Isaac Morland <isaac.morland@gmail.com>,
	John W Higgins <wishdev@gmail.com>, pgsql-hackers@postgresql.org,
	Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Have I found an interval arithmetic bug?
Message-ID: <20210405183754.GC12179@momjian.us>
References: <E34DA978-0C0E-4F43-97CD-278FA0C228E5@yugabyte.com>
 <20210403022126.GG29126@momjian.us>
 <20210405163310.GP6592@telsasoft.com>
 <20210405180158.GB12179@momjian.us>
 <20210405181522.GS6592@telsasoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210405181522.GS6592@telsasoft.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/20210405183754.GC12179%40momjian.us>
Precedence: bulk

On Mon, Apr  5, 2021 at 01:15:22PM -0500, Justin Pryzby wrote:
> On Mon, Apr 05, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
> > On Mon, Apr  5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> > > > https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-INPUT
> > > > « …field values can have fractional parts; for example '1.5 week' or '01:02:03.45'. Such input is converted to the appropriate number of months, days, and seconds for storage. When this would result in a fractional number of months or days, the fraction is added to the lower-order fields using the conversion factors 1 month = 30 days and 1 day = 24 hours. For example, '1.5 month' becomes 1 month and 15 days. Only seconds will ever be shown as fractional on output. »
> > 
> > I see that.  What is not clear here is how far we flow down.  I was
> > looking at adding documentation or regression tests for that, but was
> > unsure.  I adjusted the docs slightly in the attached patch.
> 
> I should have adjusted the quote to include context:
> 
> | In the verbose input format, and in SOME FIELDS of the more compact input formats, field values can have fractional parts[...]
> 
> I don't know what "some fields" means - more clarity here would help indicate
> the intended behavior.

I assume it is comparing the verbose format to the ISO 8601 time
intervals format, which I have not looked at.  Interesting I see this as
a C comment at the top of DecodeISO8601Interval();

	 *  A couple exceptions from the spec:
	 *   - a week field ('W') may coexist with other units
-->	 *   - allows decimals in fields other than the least significant unit.

I don't actually see anything in our code that doesn't support factional
values, so maybe the docs are wrong and need to be fixed.

Actually, according to our regression tests, this fails:

	SELECT '5.5 seconds 3 milliseconds'::interval;
	ERROR:  invalid input syntax for type interval: "5.5 seconds 3 milliseconds"

but that is the verbose format, I think.

> > The interaction of months/days/seconds is so imprecise that passing it
> > futher down doesn't make much sense, and suggests a precision that
> > doesn't exist, but if people prefer that we can do it.
> 
> I agree on its face that "months" is imprecise (30, 31, 27, 28 days),
> especially fractional months, and same for "years" (leap years), and hours per
> day (DST), but even minutes ("leap seconds").  But the documentation seems to
> be clear about the behavior:
> 
> | .. using the conversion factors 1 month = 30 days and 1 day = 24 hours
> 
> I think the most obvious/consistent change is for years and greater to "cascade
> down" to seconds, and not just months.

Wow, well, that is _an_ option.  Would people like that?  It is certainly
easier to explain.

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

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