Skip to content

branch-4.0: [fix](cast) Handle DST fallback in timestamp cast monotonicity #65903 - #66185

Open
github-actions[bot] wants to merge 1 commit into
branch-4.0from
auto-pick-65903-branch-4.0
Open

branch-4.0: [fix](cast) Handle DST fallback in timestamp cast monotonicity #65903#66185
github-actions[bot] wants to merge 1 commit into
branch-4.0from
auto-pick-65903-branch-4.0

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Cherry-picked from #65903

Related PR: #59399

Problem Summary: A TIMESTAMPTZ range-partitioned scan could lose rows
when a runtime filter or static predicate targeted `CAST(part_col AS
DATETIMEV2)` in a session timezone that crosses a daylight-saving
fall-back transition. The monotonicity check treated all date-like casts
as unconditionally monotonic. Pruning then folded both partition
endpoints; at the fall-back boundary the projected local time moved
backward, producing an invalid range and pruning a partition that
contained a matching value.

Make TIMESTAMPTZ-to-DATETIMEV2 monotonicity range-aware. Fixed-offset
zones remain monotonic. For dynamic zones, partitions with finite bounds
remain eligible only when `(lower, upper]` contains no fall-back
transition; unbounded ranges conservatively skip the monotonic shortcut.
Scale-reducing casts in dynamic zones also conservatively skip the
shortcut because UTC rounding can cross a fall-back transition just
outside the original bounds. Add unit coverage and a regression covering
runtime-filter and static partition pruning.

### Release note

Fix incorrect partition pruning for TIMESTAMPTZ-to-DATETIMEV2 casts
across daylight-saving fall-back transitions.
@github-actions
github-actions Bot requested a review from morningman as a code owner July 28, 2026 12:16
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hello-stephen

Copy link
Copy Markdown
Contributor

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

FE UT Coverage Report

Increment line coverage 60.00% (12/20) 🎉
Increment coverage report
Complete coverage report

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.

2 participants