github-actions[bot] commented on code in PR #65219:
URL: https://github.com/apache/doris/pull/65219#discussion_r3548382809
##########
fe/fe-core/src/main/java/org/apache/doris/clone/DynamicPartitionScheduler.java:
##########
@@ -372,23 +417,42 @@ private ArrayList<AddPartitionOp>
getAddPartitionOp(Database db, OlapTable olapT
dynamicPartitionProperty.getReplicaAllocation().toCreateStmt());
}
- // set storage_medium and storage_cooldown_time based on
dynamic_partition.hot_partition_num
+ // set storage_medium and storage_cooldown_time based on
dynamic_partition.hot_partition_num.
+ // Use `now` (UTC-based for TIMESTAMPTZ) so the cooldown boundary
+ // aligns with the partition's UTC range, not the configured
timezone.
setStorageMediumProperty(partitionProperties,
dynamicPartitionProperty, now, hotPartitionNum, idx);
if (StringUtils.isNotEmpty(storagePolicyName)) {
setStoragePolicyProperty(partitionProperties,
dynamicPartitionProperty, now, idx, storagePolicyName);
}
+ // For TIMESTAMPTZ, ensure storage lifecycle timestamps carry an
+ // explicit +00:00 suffix so they are parsed as UTC regardless of
+ // the session/JVM timezone when the partition is created.
+ if (isTimestampTz) {
+ String cooldown =
partitionProperties.get(PropertyAnalyzer.PROPERTIES_STORAGE_COOLDOWN_TIME);
+ if (cooldown != null
+ &&
!cooldown.equals(TimeUtils.longToTimeString(DataProperty.MAX_COOLDOWN_TIME_MS)))
{
+
partitionProperties.put(PropertyAnalyzer.PROPERTIES_STORAGE_COOLDOWN_TIME,
Review Comment:
The cooldown value is now rewritten to an explicit UTC string, but this
property is still analyzed as `DATETIME`, not as a TIMESTAMPTZ instant.
`PropertyAnalyzer.analyzeDataProperty()` calls
`DateLiteralUtils.createDateLiteral(value,
ScalarType.getDefaultDateType(Type.DATETIME))` and then
`unixTimestamp(TimeUtils.getTimeZone())`; for a value like `2027-01-01
00:00:00+00:00`, `DateLiteralUtils` strips the suffix and shifts using
`DateUtils.getTimeZone().getRules().getOffset(Instant.now())`. In a DST zone
such as `America/Chicago`, a July scheduler run uses UTC-05 to turn that winter
UTC boundary into `2026-12-31 19:00:00`, then `unixTimestamp(America/Chicago)`
stores it with the target date's UTC-06 offset, i.e. `2027-01-01 01:00:00Z`,
one hour after the partition upper bound. The new cooldown test uses
`Asia/Shanghai` day partitions, so it misses this. Please parse TIMESTAMPTZ
lifecycle values through an instant-aware UTC path, or format the property in
the actual `TimeUtils.getTi
meZone()` wall time for the target instant, and add a DST-zone YEAR/MONTH
regression.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
