On Sat, Apr 2, 2022 at 3:08 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Joseph Koshakow <kosh...@gmail.com> writes: > > Ok I actually remember now, the issue is with the rounding > > code in AdjustFractMicroseconds. > > ... > > I believe it's possible for `frac -= usec;` to result in a value greater > > than 1 or less than -1 due to the lossiness of int64 to double > > conversions. > > I think it's not, at least not for the interesting range of possible > values in this code. Given that abs(frac) < 1 to start with, the > abs value of usec can't exceed the value of scale, which is at most > USECS_PER_DAY so it's at most 37 or so bits, which is well within > the exact range for any sane implementation of double. It would > take a very poor floating-point implementation to not get the right > answer here. (And we're largely assuming IEEE-compliant floats these > days.)
Ah, I see. That makes sense to me. On Sat, Apr 2, 2022 at 3:10 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Joseph Koshakow <kosh...@gmail.com> writes: > > I took a stab at this issue and the attached patch (which would be > > applied on top of your v10 patch) seems to fix the issue. Feel > > free to ignore it if you're already working on a fix. > > You really only need to flip val/fval in one place. More to the > point, there's also the hh:mm:ss paths to deal with; see my v11. Good point. Thanks again for all the help! - Joe Koshakow