github-actions[bot] commented on code in PR #64366:
URL: https://github.com/apache/doris/pull/64366#discussion_r3557402612
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/StatementContext.java:
##########
@@ -477,6 +499,38 @@ public ConnectContext getConnectContext() {
return connectContext;
}
+ public Instant getStatementStartTime() {
+ return statementStartTime;
+ }
+
+ public ZoneId getStatementTimeZone() {
+ return statementTimeZone;
+ }
+
+ public long getStatementStartTimeMillis() {
+ return statementStartTime.toEpochMilli();
+ }
+
+ public int getStatementStartTimeNanoSeconds() {
+ return statementStartTime.getNano();
+ }
+
+ public void resetStatementStartTime() {
+ statementStartTime = Instant.now();
+ refreshStatementTimeZone();
+ }
+
+ public void refreshStatementTimeZone() {
+ statementTimeZone = getTimeZone(connectContext);
+ }
+
+ private static ZoneId getTimeZone(ConnectContext connectContext) {
+ if (connectContext == null || connectContext.getSessionVariable() ==
null) {
+ return ZoneId.systemDefault();
+ }
+ return ZoneId.of(connectContext.getSessionVariable().getTimeZone(),
TimeUtils.timeZoneAliasMap);
Review Comment:
This reopens the timezone-alias mismatch that the DateUtils fix was meant to
close. `getTimeZone()` resolves the raw session value through
`TimeUtils.timeZoneAliasMap`, which includes Java `ZoneId.SHORT_IDS`, so a
session value like `PST` becomes `America/Los_Angeles` for the FE-side `now()`
fold. The same raw `PST` is still sent in query globals to BE, whose timezone
cache only accepts tzdata names/offsets plus the special `CST`/`z` aliases, so
BE-side time functions keep using the default/UTC zone. With
`enable_fold_nondeterministic_fn=true`, one statement can therefore mix
FE-folded `now()` in Pacific time with BE-evaluated time expressions in a
different zone. This new StatementContext path needs the same BE-compatible
filtering as the earlier DateUtils path, or unsupported aliases need to avoid
FE folding.
##########
fe/fe-core/src/main/java/org/apache/doris/qe/PointQueryExecutor.java:
##########
@@ -437,6 +432,18 @@ private InternalService.PTabletKeyLookupRequest
buildLookupRequest(boolean inclu
return requestBuilder.build();
}
+ static void
setQueryGlobals(InternalService.PTabletKeyLookupRequest.Builder requestBuilder,
+ ConnectContext connectContext) {
+ String timeZone = connectContext.getSessionVariable().getTimeZone();
Review Comment:
This helper still reads the live session timezone, but the reusable prepared
short-circuit path can reach it after a statement-level
`SET_VAR(time_zone=...)` hint has been reverted. On a normal execution the
planner preprocesses `LogicalSelectHint` and `SelectHintSetVar` temporarily
installs the hint timezone, but `ExecuteCommand` returns through
`directExecuteShortCircuitQuery()` for reusable deterministic point queries and
skips that preprocessing. Expressions like `from_unixtime(ts)` are
deterministic, so they do not trip `hasNondeterministic()`, and BE evaluates
the cached output expression using the timezone sent here. A prepared point
query with `/*+ SET_VAR(time_zone='+00:00') */` can therefore return later
executions using the connection's reverted timezone instead of the statement
hint. Please build the lookup globals from the effective statement timezone or
reapply the scoped SET_VAR before this direct path.
--
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]
