morrySnow commented on code in PR #64795:
URL: https://github.com/apache/doris/pull/64795#discussion_r3489182155
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/literal/TimestampTzLiteral.java:
##########
@@ -64,6 +67,62 @@ public TimestampTzLiteral(TimeStampTzType dateType,
roundMicroSecond(dateType.getScale());
}
+ /**
+ * Build a TIMESTAMPTZ literal from a session-local datetime string.
+ * Strings with an explicit zone/offset keep their own timezone semantics;
+ * strings without one are interpreted in the current session timezone and
converted to UTC.
+ */
+ public static TimestampTzLiteral fromSessionTimeZone(TimeStampTzType
dateType, String s) {
+ if (DateTimeChecker.hasTimeZone(s)) {
+ return new TimestampTzLiteral(dateType, s);
+ }
+
+ return fromSessionTimeZone(dateType, new DateTimeV2Literal(s));
+ }
+
+ /**
+ * fromSessionTimeZone
+ */
+ public static TimestampTzLiteral fromSessionTimeZone(TimeStampTzType
dateType, DateTimeV2Literal literal) {
+ return fromTimeZone(dateType, literal, getSessionTimeZone());
+ }
+
+ /**
Review Comment:
## `fromTimeZone`: Explicit offset in string overrides `timeZone` parameter
```java
public static TimestampTzLiteral fromTimeZone(TimeStampTzType dateType,
String s, String timeZone) {
if (DateTimeChecker.hasTimeZone(s)) {
return new TimestampTzLiteral(dateType, s); // string's tz takes
precedence
}
return fromTimeZone(dateType, new DateTimeV2Literal(s), timeZone);
}
```
This is the correct behavior (the string's explicit offset should be
respected), but callers should be aware that the `timeZone` parameter is **only
used as a fallback** when the string lacks timezone info. This is documented in
the Javadoc, but a surprising edge case exists:
If a caller passes `timeZone="America/New_York"` with a border string that
already contains `+00:00` (e.g., a UTC timestamp from a previous call), the
method would use the string's `+00:00` instead of converting from New York to
UTC. This is correct for most use cases, but could lead to subtle bugs if a
caller accidentally passes a UTC string when they intended a different timezone.
Consider adding a `@param timeZone Fallback timezone used only when the
string has no explicit offset` to the Javadoc to make this crystal clear.
--
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]
