SEPURI-SAI-KRISHNA opened a new pull request, #59135: URL: https://github.com/apache/spark/pull/59135
### What changes were proposed in this pull request? This PR makes `date_add` and `date_sub` (`DateAdd` / `DateSub`) fail with `DATETIME_OVERFLOW` when the resulting number of days does not fit in an `Int`, instead of silently wrapping around. It adds `DateTimeUtils.dateAddDays` / `dateSubtractDays`, which use `Math.addExact` / `Math.subtractExact`, and uses them in both the interpreted and the generated code. This also covers the operators and functions that resolve to these expressions: `date + int`, `date - int`, `dateadd`, and `try_add` / `try_subtract` on dates, which now return `NULL` on overflow as documented. ### Why are the changes needed? The days were added with plain `Int` arithmetic, so an overflowing result wrapped around to a wrong but valid-looking date, with ANSI mode on and off: ```sql SELECT date_add(DATE'2020-01-01', 2147483647); -- -5877591-06-21 SELECT date_sub(DATE'1900-01-01', 2147483647); -- +5881510-07-14 SELECT try_add(DATE'2020-01-01', 2147483647); -- -5877591-06-21 instead of NULL ``` Similar operations already fail in this case, e.g. `add_months(DATE'2020-01-01', 2147483647)` raises `ARITHMETIC_OVERFLOW` and `DATE'2020-01-01' + make_dt_interval(2147483647, 0, 0, 0)` raises `INTERVAL_ARITHMETIC_OVERFLOW`. The error class follows `TIMESTAMPADD`, which raises `DATETIME_OVERFLOW` since SPARK-38481. ### Does this PR introduce _any_ user-facing change? Yes. When the result of `date_add` / `date_sub` does not fit in the date range, it now fails instead of returning a wrong date: ``` [DATETIME_OVERFLOW] Datetime operation overflow: add 2147483647 days to DATE '2020-01-01'. SQLSTATE: 22008 ``` `try_add` / `try_subtract` on dates return `NULL` in that case. Results that fit are unchanged. ### How was this patch tested? - New tests in `DateExpressionsSuite` for overflow in both directions and for the largest values that still fit, in both interpreted and codegen mode. The existing consistency checks for `IntegerType` now allow both paths to throw. The new tests fail without this change. - Ran the queries above on a table (not constant folded) with whole-stage codegen and interpreted mode, with ANSI mode on and off. - Ran `DateExpressionsSuite`, `DateTimeUtilsSuite`, `DateFunctionsSuite`, and the date, timestamp, interval and try_arithmetic tests in `SQLQueryTestSuite`. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5.5) -- 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]
