Re: BUG #19670: Silent Integer Overflow in time_pl_interval() Returns Wrong Time Value

Rahul Yadav <rahul(at)rhyadav(dot)com> wrote:
> Since the result wraps around at midnight anyway, only the interval's
> time field modulo one day matters. The attached patch reduces it
> first, so the intermediate result always fits in an int64; results
> for intervals that didn't overflow are unchanged. It also adds
> regression tests for the largest and smallest interval time values,
> which fail without the fix.

I applied v1 on top of 3c5d9d914f, built it on macos clang 17 with
assertions enabled and ran the regression tests; they pass, and the new
ones fail without the date.c change. The example from the report now
gives 04:00:53.999999.

The fix looks right to me. Since 0 <= time <= USECS_PER_DAY and the
reduced offset is in (-USECS_PER_DAY, USECS_PER_DAY), the sum can't
overflow, and the existing normalization maps it to the same result as
before. I also compared time +/- interval against an exact numeric
computation for a couple of thousand random interval values plus the
boundaries: the results match HEAD wherever HEAD doesn't overflow, and
are correct where it does. The timetz zone is never touched.

Best regards,
Andrew Krylosov