[SPARK-60073][SQL] Return NULL from try_make_timestamp for a year outside the timestamp range - #59292

What changes were proposed in this pull request?

MakeTimestamp with failOnError = false now returns NULL when converting the result to microseconds overflows, in both the interpreted and the codegen path. Before, it only caught DateTimeException, while a year outside the microsecond timestamp range (about |year| > 294247) is valid for java.time and only fails later in instantToMicros with an ArithmeticException from Math.multiplyExact.

try_make_timestamp, try_make_timestamp_ntz and try_make_timestamp_ltz all build MakeTimestamp(..., failOnError = false), so the fix covers all three, as well as make_timestamp with ANSI off.

Why are the changes needed?

These functions are documented to return NULL on invalid input, but a large year throws instead:

SELECT try_make_timestamp(999999, 1, 2, 3, 4, 5);
-- before: java.lang.ArithmeticException: long overflow
-- after:  NULL

Does this PR introduce any user-facing change?

Yes. try_make_timestamp, try_make_timestamp_ntz, try_make_timestamp_ltz, and make_timestamp with spark.sql.ansi.enabled=false, return NULL instead of throwing java.lang.ArithmeticException: long overflow when the year is outside the timestamp range. make_timestamp with ANSI on is unchanged.

How was this patch tested?

Added a test to DateExpressionsSuite covering TIMESTAMP and TIMESTAMP_NTZ with years 999999 and -999999. checkEvaluation runs the interpreted, codegen and constant-folded paths. I checked that the test fails when either the interpreted or the codegen catch is removed.

build/sbt 'catalyst/testOnly *DateExpressionsSuite'

Not covered

1. The (date[, time[, timezone]]) overloads of try_make_timestamp and try_make_timestamp_ltz go through MakeTimestampFromDateTime, which has no non-failing mode, so a date outside the timestamp range still throws there:

   TryMakeTimestampFromDateTime(DATE of epoch day 365000000, TIME 00:00:00, 'UTC')  ->  ArithmeticException: long overflow
   

   try_make_timestamp_ntz(date, time) is wrapped in TryEval and returns NULL for the same date. Wrapping the other two in TryEval would also turn an invalid time zone into NULL, and would change the default column name of try_make_timestamp_ltz(date, time) from make_timestamp(...) to tryeval(make_timestamp(...)).

2. While checking that, I noticed that MakeTimestamp with failOnError = false handles an invalid time zone differently in the two paths: the interpreted path throws INVALID_TIMEZONE, because it resolves the zone before the try, while the codegen path resolves it inside the try and returns NULL.

I left both out to keep this change to the overflow. Happy to handle either here or in a separate PR, whichever you prefer.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code (claude-opus-5-5)

🤖 Generated with Claude Code