github-actions[bot] commented on code in PR #70485:
URL: https://github.com/apache/doris/pull/70485#discussion_r4545651907
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/literal/TimestampTzLiteral.java:
##########
@@ -363,8 +368,30 @@ public Expression plusWeeks(long weeks) {
return fromJavaDateType(toJavaDateType().plusWeeks(weeks),
getDataType().getScale());
}
+ /**
+ * Add calendar years in the session time zone and return the UTC result.
+ */
public Expression plusYears(long years) {
- return fromJavaDateType(toJavaDateType().plusYears(years),
getDataType().getScale());
+ // Use the session date for calendar years. For example, 2024-02-29
00:00 in
+ // +08:00 must become 2025-02-28 00:00, although its UTC date is
February 28.
+ ZoneId zone =
TimeUtils.getOrSystemTimeZone(getSessionTimeZone()).toZoneId();
+ ZonedDateTime local =
toJavaDateType().atZone(ZoneOffset.UTC).withZoneSameInstant(zone);
+ LocalDateTime target = local.toLocalDateTime().plusYears(years);
Review Comment:
[P2] Apply Doris's year-zero leap rule before converting back to UTC
`LocalDateTime.plusYears` treats year zero as a leap year, while Doris's
`is_leap(0)` is false. In session `+08:00`, `years_add(CAST('2024-02-29
00:00:00 +08:00' AS TIMESTAMPTZ(6)), -2024)` now folds through local
`0000-02-29 00:00` to UTC `0000-02-28 16:00`. The new BE path reuses
`DateV2Value::date_add_interval<YEAR>`, clamps that target to local February 28
and returns UTC `0000-02-27 16:00` instead. Both final UTC dates are valid, so
the FE's final validation does not trigger fallback. Previously both paths
changed the stored UTC February 28 and agreed. Apply Doris's local-calendar
leap/validity policy before UTC conversion and add FE/BE parity tests for this
supported boundary, including subtraction.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/literal/TimestampTzLiteral.java:
##########
@@ -363,8 +368,30 @@ public Expression plusWeeks(long weeks) {
return fromJavaDateType(toJavaDateType().plusWeeks(weeks),
getDataType().getScale());
}
+ /**
+ * Add calendar years in the session time zone and return the UTC result.
+ */
public Expression plusYears(long years) {
- return fromJavaDateType(toJavaDateType().plusYears(years),
getDataType().getScale());
+ // Use the session date for calendar years. For example, 2024-02-29
00:00 in
+ // +08:00 must become 2025-02-28 00:00, although its UTC date is
February 28.
+ ZoneId zone =
TimeUtils.getOrSystemTimeZone(getSessionTimeZone()).toZoneId();
+ ZonedDateTime local =
toJavaDateType().atZone(ZoneOffset.UTC).withZoneSameInstant(zone);
Review Comment:
[P1] Update year-arithmetic pruning ranges for the session calendar
`YearsAdd`/`YearsSub` still inherit `CalendarAddSubMonotonic`, whose day
checks and clamp bounds use UTC fields. With `time_zone='+08:00'`, consider
this reduced plan (partition bounds shown in UTC):
```
Filter(years_add(ts, 1) = CAST('2025-02-27 16:30:00 +00:00' AS
TIMESTAMPTZ(6)))
Scan(ts partition: [2024-02-28 12:00 UTC, 2024-03-01 00:00 UTC))
```
`inferRange` folds the endpoints and widens the lower bound only to
`2025-02-28 00:00 UTC`, retaining upper `2025-03-01 00:00 UTC`. However, the
interior row `ts=2024-02-28 16:30 UTC` is local February 29 00:30, so the new
calculation returns `2025-02-27 16:30 UTC`, which matches the filter but lies
below the inferred range. `OneRangePartitionEvaluator` intersects that range
with the equality, obtains FALSE and drops the matching partition. Update or
conservatively disable the TIMESTAMPTZ year range inference, accounting for
local clamping and DST, and add partition-pruning coverage.
--
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]
