morrySnow commented on code in PR #64795:
URL: https://github.com/apache/doris/pull/64795#discussion_r3489177924
##########
fe/fe-core/src/main/java/org/apache/doris/clone/DynamicPartitionScheduler.java:
##########
@@ -483,9 +493,28 @@ private void setStoragePolicyProperty(HashMap<String,
String> partitionPropertie
partitionProperties.put(PropertyAnalyzer.PROPERTIES_DATA_BASE_TIME,
baseTime);
}
+ /**
+ * For TIMESTAMPTZ partition columns, convert the border string from the
partition's
+ * timezone to a UTC timestamp string (with +00:00 suffix). This ensures
partition
Review Comment:
## `TimeStampTzType.SYSTEM_DEFAULT` loses sub-second precision in
intermediate representation
```java
TimestampTzLiteral utcLiteral = TimestampTzLiteral.fromTimeZone(
TimeStampTzType.SYSTEM_DEFAULT, border,
timeZone.toZoneId().toString());
return utcLiteral.getStringValue();
```
`SYSTEM_DEFAULT` has scale=0. The returned string (e.g., `"2024-06-15
04:00:00+00:00"`) lacks sub-second digits. This is **functionally correct**
because `DynamicPartitionUtil.getPartitionRangeString()` always returns
whole-second boundaries (no sub-second part), and the final
`PartitionKey.createPartitionKey()` uses the column's actual scale to
reconstruct the literal.
However, using `SYSTEM_DEFAULT` here is semantically misleading — it implies
scale=0 is an intentional choice for this conversion, when it's actually just
an artifact of the intermediate representation. Consider either:
- Passing the column's actual scale (e.g., `((ScalarType)
column.getType()).getScalarScale()`)
- Or adding a comment explaining why scale=0 is safe in this context
(because borders are always whole-second aligned)
--
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]
