github-actions[bot] commented on code in PR #67493:
URL: https://github.com/apache/doris/pull/67493#discussion_r3923935619
##########
be/src/exprs/function/function_convert_tz.cpp:
##########
@@ -252,7 +239,9 @@ class FunctionConvertTZ : public IFunction {
DateValueType ts_value = date_column->get_element(i);
DateValueType ts_value2;
- ts_value2.from_unixtime(unix_timestamp_for_convert_tz(ts_value,
from_tz), to_tz);
+ std::pair<int64_t, int64_t> timestamp;
+ ts_value.unix_timestamp(×tamp, from_tz);
Review Comment:
[P1] Preserve old-FE pruning semantics during BE-first upgrades
[Doris upgrades BEs before
FEs](https://doris.apache.org/docs/dev/admin-manual/cluster-management/upgrade/),
so this unconditional result change runs while an old FE can still certify
every fixed-target `convert_tz` as monotonic and fold source-gap endpoints with
the old zero-fraction policy. With the same Europe/Paris rules on both sides,
an old FE can project a `DATETIMEV2(6)` partition `[2021-03-28 02:00:00,
2021-03-28 03:00:00)` to the singleton `01:00:00` and prune it for
`convert_tz(ts,'Europe/Paris','UTC') > '2021-03-28 01:00:00.500000'`. This new
BE path maps a stored `02:30:00.900000` to `01:00:00.900000`, so that pruned
row actually matches.
Please stage this semantic change behind an old-FE/new-BE compatibility
contract (for example, a query capability or versioned function
implementation), and add a mixed-version pruning regression, so the supported
rolling-upgrade window cannot drop rows.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/scalar/ConvertTz.java:
##########
@@ -124,15 +123,24 @@ public boolean isMonotonic(Literal lower, Literal upper) {
if (upperDateTime.isBefore(lowerDateTime)) {
return false;
}
+ if (mayHaveFractionalSecondSourceGap(fromZone)
Review Comment:
[P1] Avoid FE-only timezone rules when certifying source-gap monotonicity
`hasGapResetInRange` can return false merely because the FE JVM's tzdb has
no transition, but BEs load independently versioned `TZDIR`/system tzdata, so
the resulting `true` is not safe. A released example is `America/Asuncion`:
[tzdb 2025a](https://data.iana.org/time-zones/tzdb-2025a/southamerica) makes it
permanent -03, while [tzdb
2024b](https://data.iana.org/time-zones/tzdb-2024b/southamerica) still has the
2025-10-05 00:00-to-01:00 spring gap. With a 2025a FE and 2024b BE:
`Filter(convert_tz(ts,'America/Asuncion','UTC') >= '2025-10-05
04:00:00.500000')`
` Scan p: ts in [2025-10-05 00:00:00, 2025-10-05 01:00:00)`
FE derives an image around `[03:00,04:00]` and can prune `p`, but under this
PR's retained-fraction behavior the BE maps stored `00:00:00.500000` to
`04:00:00.500000`, so that row matches. `RuntimeFilterPruneClassifier` trusts
the same certification. Unless FE and every BE share a versioned timezone-rules
contract, please keep positive-scale named/non-fixed source zones
conservatively non-monotonic and add an end-to-end pruning regression.
--
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]
