Skip to content

repr, expr: roll leap-second timestamps into the next minute - #38107

Closed
def- wants to merge 1 commit into
MaterializeInc:pr-per-53from
def-:pr-per-63
Closed

repr, expr: roll leap-second timestamps into the next minute#38107
def- wants to merge 1 commit into
MaterializeInc:pr-per-53from
def-:pr-per-63

Conversation

@def-

@def- def- commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

chrono represents a parsed :60 second as 59 with nanos >= 1e9, a value
that sorts before the following second while the epoch family (extract
epoch, casts to mz_timestamp, timestamp subtraction, date_bin, precision
rounding) counts it at or past that second. That breaks the monotonicity
contracts persist filter pushdown narrows ranges with: an interior leap
value escapes the endpoint-derived range, so a part holding one could be
wrongly discarded. Roll :60 over at the parse boundary, matching Postgres,
so the leap representation never enters a timestamp. TIME keeps it:
rolling a time over would wrap to 00:00:00 and reverse its ordering, and
the whole-second leap time is provably harmless (fractional leap seconds
are rejected at parse for all types).

add_date_time is the other way a leap representation reached a timestamp.
It passed a leap-second TIME's raw nanos straight through, so DATE + TIME
'23:59:60' still constructed one and disagreed with the equivalent
timestamp literal. It now rolls over the same way.

Both rollovers can overflow chrono's range: TIMESTAMP '262142-12-31
23:59:60' parses, because that is chrono's max date and the leap value
passes the HIGH_DATE check, and adding the rollover second overflows.
Overflow reports out of range in the timestamp, timestamptz, and
DATE + TIME paths instead of panicking.

Closes: PER-63

Builds on top of #38076

chrono represents a parsed :60 second as 59 with nanos >= 1e9, a value
that sorts before the following second while the epoch family (extract
epoch, casts to mz_timestamp, timestamp subtraction, date_bin, precision
rounding) counts it at or past that second. That breaks the monotonicity
contracts persist filter pushdown narrows ranges with: an interior leap
value escapes the endpoint-derived range, so a part holding one could be
wrongly discarded. Roll :60 over at the parse boundary, matching Postgres,
so the leap representation never enters a timestamp. TIME keeps it:
rolling a time over would wrap to 00:00:00 and reverse its ordering, and
the whole-second leap time is provably harmless (fractional leap seconds
are rejected at parse for all types).

add_date_time is the other way a leap representation reached a timestamp.
It passed a leap-second TIME's raw nanos straight through, so DATE + TIME
'23:59:60' still constructed one and disagreed with the equivalent
timestamp literal. It now rolls over the same way.

Both rollovers can overflow chrono's range: TIMESTAMP '262142-12-31
23:59:60' parses, because that is chrono's max date and the leap value
passes the HIGH_DATE check, and adding the rollover second overflows.
Overflow reports out of range in the timestamp, timestamptz, and
DATE + TIME paths instead of panicking.

Closes: PER-63

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@def-
def- requested review from a team as code owners August 7, 2026 10:55
@def-
def- changed the base branch from main to pr-per-53 August 7, 2026 11:00
@def- def- closed this Aug 7, 2026
@def-

def- commented Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

Superseded by #38109 (same commit, head branch in this repo so it can take part in a GitHub stack). Middle of stack #38111: #38108#38109#38110.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant