Skip to content

branch-4.1: [fix](fe) Accept spaced TIMESTAMPTZ offsets in range partition bounds - #66292

Merged
yiguolei merged 1 commit into
apache:branch-4.1from
starocean999:b41_0730
Jul 30, 2026
Merged

branch-4.1: [fix](fe) Accept spaced TIMESTAMPTZ offsets in range partition bounds #66292
yiguolei merged 1 commit into
apache:branch-4.1from
starocean999:b41_0730

Conversation

@starocean999

Copy link
Copy Markdown
Contributor

pick #64795 and #65219

…che#64795)

[fix](timestamptz) Fix TIMESTAMPTZ dynamic partition boundaries not aligned to UTC midnight (apache#65219)

Related PR: apache#64795

Problem Summary:
When a table has a `TIMESTAMPTZ` partition column and
`dynamic_partition.time_zone` is set to a non-UTC timezone (e.g.,
`Asia/Shanghai`), the dynamically created partition boundaries are
shifted to midnight in the configured timezone rather than UTC midnight.

**Root cause:** `getAddPartitionOp()` computed the current date (`now`)
in the configured timezone, then `convertToUtcTimestamp()` interpreted
the resulting date string as midnight in that timezone and converted it
to UTC — producing a timezone-offset hour (e.g., 16:00) instead of UTC
midnight (00:00). Both the `now` computation and the timezone used in
`convertToUtcTimestamp()` needed to be fixed.

In `DynamicPartitionScheduler.getAddPartitionOp()`, decouple the time
references for boundary computation and naming:

1. **Boundary computation**: For `TIMESTAMPTZ`, use
`ZonedDateTime.now(UTC)` for the current clock and pass UTC as the
source timezone to `convertToUtcTimestamp()`. This ensures partition
boundaries are at UTC midnight (00:00–24:00) regardless of
`dynamic_partition.time_zone`.

2. **Partition naming**: For TIMESTAMPTZ columns, partition names are
now generated from the same UTC-based clock as partition boundary
values, via a shared setupDynamicPartitionTime() context. This keeps
names and values consistent — both reflect UTC 00:00–24:00 boundaries —
instead of the previous approach where names used the configured
timezone's wall clock while values used UTC, which could misalign at
timezone boundaries (e.g., a day partition named p20270101 but spanning
[[2027-01-01 08:00 UTC, 2027-01-02 08:00 UTC) under Asia/Shanghai). For
non-TIMESTAMPTZ columns, the dynamic_partition.time_zone property
continues to control naming (e.g., week-of-year computation for week
partitions) as before.

3. **Storage properties**: `setStorageMediumProperty()` and
`setStoragePolicyProperty()` also use the configured-timezone `nowTz` so
hot partition determination stays consistent with naming.
@starocean999
starocean999 requested a review from yiguolei as a code owner July 30, 2026 09:59
@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?

@starocean999

Copy link
Copy Markdown
Contributor Author

run buildall

@starocean999 starocean999 changed the title (fe) Accept spaced TIMESTAMPTZ offsets in range partition bounds branch-4.1: [fix](fe) Accept spaced TIMESTAMPTZ offsets in range partition bounds Jul 30, 2026
@github-actions github-actions Bot added the approved Indicates a PR has been approved by one committer. label Jul 30, 2026
@github-actions

Copy link
Copy Markdown
Contributor

PR approved by at least one committer and no changes requested.

@github-actions

Copy link
Copy Markdown
Contributor

PR approved by anyone and no changes requested.

@yiguolei

Copy link
Copy Markdown
Contributor

skip buildall

@yiguolei
yiguolei merged commit e7e6a57 into apache:branch-4.1 Jul 30, 2026
32 of 34 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants