github-actions[bot] commented on code in PR #65219:
URL: https://github.com/apache/doris/pull/65219#discussion_r3636145854
##########
fe/fe-core/src/main/java/org/apache/doris/analysis/DateLiteralUtils.java:
##########
@@ -216,6 +211,27 @@ public static DateLiteral createDateLiteral(String s,
@Nullable Type type) throw
}
}
+ // Recompute the timezone offset using the target date rather than
+ // Instant.now(), so DST-sensitive zones (e.g. America/Chicago)
+ // produce the correct shift regardless of when the code runs.
+ // The original code used Instant.now() which returns the current
+ // DST offset; when the target date falls in a different DST period
+ // the computed shift is wrong by the DST gap.
+ if (sourceZone != null) {
+ // Use TimeUtils.getTimeZone() for consistency with the
+ // downstream unixTimestamp(TimeUtils.getTimeZone()) call.
+ ZoneId dorisZone = TimeUtils.getTimeZone().toZoneId();
+ if (type != null && type.isTimeStampTz()) {
+ dorisZone = ZoneId.of("UTC");
+ }
+ LocalDateTime parsedLdt = LocalDateTime.of(
+ (int) year, (int) month, (int) day,
+ (int) hour, (int) minute, (int) second);
+ Instant targetInstant =
parsedLdt.atZone(sourceZone).toInstant();
Review Comment:
[P2] Preserve the source-zone gap adjustment
Named suffixes such as `CET` are accepted here and can contain DST gaps.
Java resolves `2027-03-28 02:30:00CET` forward to `03:30+02:00`, i.e. `01:30Z`,
but this code keeps only that resolved instant for the offset lookup and later
applies `+02:00` to the original nonexistent `02:30`, constructing `00:30Z`.
The result is one hour earlier than Java's resolved source instant. Please
construct the destination fields directly from `targetInstant` (for example
with `LocalDateTime.ofInstant(targetInstant, dorisZone)`) or reject source-zone
gaps, and add DATETIME/TIMESTAMPTZ coverage for this case.
##########
fe/fe-core/src/main/java/org/apache/doris/analysis/DateLiteralUtils.java:
##########
@@ -216,6 +211,27 @@ public static DateLiteral createDateLiteral(String s,
@Nullable Type type) throw
}
}
+ // Recompute the timezone offset using the target date rather than
+ // Instant.now(), so DST-sensitive zones (e.g. America/Chicago)
+ // produce the correct shift regardless of when the code runs.
+ // The original code used Instant.now() which returns the current
+ // DST offset; when the target date falls in a different DST period
+ // the computed shift is wrong by the DST gap.
+ if (sourceZone != null) {
+ // Use TimeUtils.getTimeZone() for consistency with the
+ // downstream unixTimestamp(TimeUtils.getTimeZone()) call.
+ ZoneId dorisZone = TimeUtils.getTimeZone().toZoneId();
+ if (type != null && type.isTimeStampTz()) {
+ dorisZone = ZoneId.of("UTC");
+ }
+ LocalDateTime parsedLdt = LocalDateTime.of(
+ (int) year, (int) month, (int) day,
+ (int) hour, (int) minute, (int) second);
+ Instant targetInstant =
parsedLdt.atZone(sourceZone).toInstant();
+ offset =
dorisZone.getRules().getOffset(targetInstant).getTotalSeconds()
Review Comment:
[P1] Keep TIMESTAMPTZ rendering on one target offset
`ExprToStringValueVisitor` passes the internal UTC value through this
helper, but then appends `dorisZone.getRules().getOffset(Instant.now())`. In an
America/Chicago session running during summer, `2027-01-01 00:00:00+00:00` is
now converted here to the correct winter wall time `2026-12-31 18:00:00`, then
the visitor appends the current `-05:00`; the emitted value represents
`23:00Z`, one hour before the original instant. That visitor feeds constant
result rows and transactional insert/stream-load materialization, so this can
return or insert the wrong TIMESTAMPTZ value. Please render from the original
instant with one consistently selected zone/target-instant offset (and cover a
winter target while execution is in summer).
--
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]
