Doris-Breakwater commented on issue #68723: URL: https://github.com/apache/doris/issues/68723#issuecomment-5978384567
Breakwater-GitHub-Analysis-Slot: slot_7bc24db9955d **Triage: confirmed FE/BE date semantics mismatch in the reported 4.1.4 source (correctness bug).** I inspected the local `4.1.4` tag, which resolves to the reported `ad35a140c7f` commit. The SQL results are from the report; I did not run a Doris cluster independently. The issue has no labels. **Code evidence** - Nereids folds `date_add` through `daysAdd` and `DateV2Literal.plusDays`, which calls `LocalDateTime.plusDays` ([FE arithmetic](https://github.com/apache/doris/blob/4.1.4/fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/executable/DateTimeArithmetic.java#L300-L305), [literal](https://github.com/apache/doris/blob/4.1.4/fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/literal/DateV2Literal.java#L61-L63)). FE `last_day` similarly uses `LocalDateTime` month arithmetic ([implementation](https://github.com/apache/doris/blob/4.1.4/fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/executable/DateTimeExtractAndTransform.java#L488-L493)). Java's proleptic ISO calendar treats year 0 as leap, explaining the folded February 29. - BE `is_leap(0)` is false because of `&& year` ([helper](https://github.com/apache/doris/blob/4.1.4/be/src/util/time_lut.h#L36-L38)). BE `last_day` calls this helper ([implementation](https://github.com/apache/doris/blob/4.1.4/be/src/exprs/function/function_other_types_to_date.cpp#L1090-L1095)); DATEV2 day addition uses day numbers and converts them back with the same non-leap-year rule ([date arithmetic](https://github.com/apache/doris/blob/4.1.4/be/src/core/value/vdatetime_value.cpp#L2470-L2492), [conversion](https://github.com/apache/doris/blob/4.1.4/be/src/core/value/vdatetime_value.cpp#L2412-L2435)). This explains March 1 and February 28 at execution. - The existing FE parser explicitly accepts February 29 only when `year > 0` ([validation](https://github.com/apache/doris/blob/4.1.4/fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/literal/DateLiteral.java#L379-L390)); an existing FE test expects `0000-02-29` to be rejected ([test](https://github.com/apache/doris/blob/4.1.4/fe/fe-core/src/test/java/org/apache/doris/nereids/rules/expression/FoldConstantTest.java#L1311-L1319)). The folding path constructs a date from Java's result without applying that parser check, so it can emit a value that direct literal parsing rejects. **Suggested next steps** 1. Keep year-0 behavior consistent with the existing date validity contract when fixing FE folding, or explicitly decide and document a calendar change across FE and BE. Removing `&& year` in BE alone would also change parsing, arithmetic, and calendar behavior; it would not resolve the existing contract mismatch by itself. 2. Add paired folded and BE-executed regression cases for DATEV2 and DATETIMEV2 around `0000-02-28`/`0000-03-01`: `date_add`, `last_day`, `dayofyear`, `weekday`, and `week` (including relevant modes). Cover rejection of a direct `0000-02-29` literal and check the plan result against execution. FE has special cases for some year-0 calendar functions, so test dates beyond March 1 as well. The supplied SQL, version, and plans are sufficient for initial triage; no additional logs or profile are needed to identify this mismatch. A fix should still be verified against a running 4.1.4-compatible build and the relevant date regression suite. -- 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]
