Skip to content

[fix](dynamic partition) Fix timezone mismatch in hot partition cooldown time computation#62529

Open
shuke987 wants to merge 1 commit intoapache:branch-4.1from
shuke987:4.1-case-fix
Open

[fix](dynamic partition) Fix timezone mismatch in hot partition cooldown time computation#62529
shuke987 wants to merge 1 commit intoapache:branch-4.1from
shuke987:4.1-case-fix

Conversation

@shuke987
Copy link
Copy Markdown
Collaborator

Summary

  • DynamicPartitionScheduler.setStorageMediumProperty formats cooldown time in partition timezone but PropertyAnalyzer.analyzeDataProperty parses it in FE server timezone — classic implicit-timezone bug
  • When dynamic_partition.time_zone differs from FE timezone (e.g., Europe/London vs CST), cooldown time shifts by the offset (up to ±15h), causing intermittent Cool down time should later than now error
  • Fix: parse partition-timezone string → ZonedDateTime with correct zone → epoch ms → TimeUtils.longToTimeString() (FE timezone), matching what analyzeDataProperty expects

Changes

  • DynamicPartitionScheduler.java: 10-line fix in setStorageMediumProperty else branch
  • DynamicPartitionTableTest.java: 3 new test cases covering:
    1. DAY granularity + UTC+0 timezone (8h diff from CST)
    2. HOUR granularity + America/Los_Angeles (15-16h diff from CST)
    3. Same timezone as FE (regression guard)

Each test independently computes the expected cooldown epoch and asserts ≤1h deviation — catches the 8-15h timezone shift regardless of when the test runs.

Closes DORIS-25127

Test plan

  • FE UT: DynamicPartitionTableTest.testHotPartitionCooldownTimeWithNonDefaultTimezone
  • Verify usercases.XB.load.load passes in branch-4.1 Usercase pipeline

🤖 Generated with Claude Code

…own time computation

setStorageMediumProperty formats the cooldown time string using the
partition's timezone (via getPartitionRangeString with DATETIME_FORMAT),
but analyzeDataProperty parses it using the FE server timezone
(TimeUtils.getTimeZone). When these differ, the cooldown time shifts
by the timezone offset (up to ±15 hours), which can push it into the
past and trigger "Cool down time should later than now" error.

Fix: parse the partition-timezone string back to a ZonedDateTime with
the correct zone, convert to epoch millis, then re-format using
TimeUtils.longToTimeString() which uses the FE timezone — matching
what analyzeDataProperty expects.

Closes DORIS-25127

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@shuke987 shuke987 requested a review from yiguolei as a code owner April 15, 2026 12:54
@Thearas
Copy link
Copy Markdown
Contributor

Thearas commented Apr 15, 2026

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?

@shuke987
Copy link
Copy Markdown
Collaborator Author

run buildall

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