[Bug] make_date accepts year 0 and negative years that Spark rejects

[andygrove]

Describe the bug

make_date(year, month, day) in Comet accepts year = 0 and negative years, returning a valid date built via chrono's proleptic Gregorian calendar. Spark rejects these (returns NULL in non-ANSI mode, throws under ANSI). The Rust test test_make_date_extreme_years in native/spark-expr/src/datetime_funcs/make_date.rs acknowledges this acceptance.

Steps to reproduce

SELECT make_date(0, 1, 1);
-- Spark: NULL (or throws under ANSI)
-- Comet: 0000-01-01

SELECT make_date(-1, 1, 1);
-- Spark: NULL (or throws under ANSI)
-- Comet: -0001-01-01

Expected behavior

Match Spark: reject years outside [1, 9999].

Additional context

Surfaced by the date/time audit (#4448). Reproducer captured as an ignored test in spark/src/test/resources/sql-tests/expressions/datetime/make_date.sql; remove the ignore(...) when this is fixed.

[andygrove]

After a closer look at Spark, this is not a divergence. Spark's MakeDate.nullSafeEval uses LocalDate.of(year, month, day) (datetimeExpressions.scala:2453 in v3.5.8), which accepts any year in [-999999999, 999999999] (the Java LocalDate range). chrono's NaiveDate::from_ymd_opt accepts the same range, so year 0 and negative years produce the same date on both engines.

The existing SQL tests at spark/src/test/resources/sql-tests/expressions/datetime/make_date.sql:133,136 exercise make_date(0, 1, 1) and make_date(-1, 1, 1) in default query mode and pass, confirming no divergence. The audit finding that produced this issue was overstated: Spark's @ExpressionDescription documents the range as 1..9999 but the implementation does not enforce that bound.