time values past 24:00:00 (or rather 23:59:60)
This is ok:
# select '23:59:60'::time;
time
──────────
24:00:00
# select '23:59:61'::time;
ERROR: 22008: date/time field value out of range: "23:59:61"
This is not ok:
# select '23:59:60.999'::time;
time
──────────────
24:00:00.999
-- value isn't read back:
# select '24:00:00.999'::time;
ERROR: 22008: date/time field value out of range: "24:00:00.999"
-- we can even go to :01
# select '23:59:60.9999999'::time;
time
──────────
24:00:01
PG 12.3.
Christoph
Christoph Berg <myon@debian.org> writes:
This is not ok:
# select '23:59:60.999'::time;
time
--------------
24:00:00.999
Yeah. Here's a draft patch for that (sans any regression tests as yet).
I found several places with largely the same logic, so I tried to
centralize the tests; although it turns out we need a minimum of
two versions, because some places deal with fractional seconds
differently.
The places using float seconds had their own bugs: one forgot to worry
about NaN, and neither was being careful about imprecise input.
It's slightly annoying to have the check functions duplicate the
calculation that some level of caller is going to do, but avoiding that
would take more refactoring than I think is warranted. In practice a
few extra multiplications aren't likely to be noticeable here.
regards, tom lane
Attachments:
handle-maximum-time-of-day-better.patchtext/x-diff; charset=us-ascii; name=handle-maximum-time-of-day-better.patchDownload+74-38
I wrote:
Christoph Berg <myon@debian.org> writes:
This is not ok:
# select '23:59:60.999'::time;
time
--------------
24:00:00.999
Yeah. Here's a draft patch for that (sans any regression tests as yet).
I pushed this fix, but only as far back as v10. To apply it in the
9.x branches, we'd need to make the code support float timestamps,
and I didn't think it was worth the trouble.
regards, tom lane