feat: add support for date_from_unix_date expression

[andygrove]

Summary

• Adds native Comet support for Spark's date_from_unix_date function
• The function converts an integer (days since Unix epoch 1970-01-01) to a Date32 value
• Implementation is straightforward since Arrow's Date32 already stores days since epoch

Test Plan

• Added unit tests in CometTemporalExpressionSuite
• Tests cover: epoch date, positive/negative days, null handling
• All existing tests pass

Note: This PR was generated with AI assistance.

Closes #3089

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.96%. Comparing base (f09f8af) to head (b2cdd60).
⚠️ Report is 907 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #3144      +/-   ##
============================================
+ Coverage     56.12%   59.96%   +3.83%     
- Complexity      976     1473     +497     
============================================
  Files           119      175      +56     
  Lines         11743    16169    +4426     
  Branches       2251     2682     +431     
============================================
+ Hits           6591     9695    +3104     
- Misses         4012     5126    +1114     
- Partials       1140     1348     +208     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[andygrove]

Moving this to draft until #3328 is merged

[mbutrovich]

Thanks @andygrove! Claude summarized my notes for me. Hopefully it didn't transcribe anything wrong or hallucinate :)

PR #3144: date_from_unix_date

Nice straightforward expression. A few things I noticed:

Scalar path returns Array instead of Scalar

The scalar branch in date_from_unix_date.rs converts the input to a 1-element array and returns ColumnarValue::Array. This breaks the scalar-in/scalar-out contract that DataFusion expects for proper broadcast semantics. When date_from_unix_date(0) is used as a literal, returning a 1-element array instead of a scalar could cause issues with downstream columnar operations.

The fix would be to extract the ScalarValue::Int32 directly and return ScalarValue::Date32:

ColumnarValue::Scalar(scalar) => {
    match scalar {
        ScalarValue::Int32(Some(days)) => {
            Ok(ColumnarValue::Scalar(ScalarValue::Date32(Some(days))))
        }
        ScalarValue::Int32(None) | ScalarValue::Null => {
            Ok(ColumnarValue::Scalar(ScalarValue::Date32(None)))
        }
        _ => Err(DataFusionError::Execution(
            "date_from_unix_date expects Int32 scalar input".to_string(),
        )),
    }
}

Docs

docs/spark_expressions_support.md still has date_from_unix_date marked as [ ]. Should be [x].

Tests

It might be worth adding Int32 boundary values (2147483647, -2147483648) to the test INSERT to match Spark's own testIntegralInput coverage. The implementation is identity so it can't overflow, but boundary tests document that the behavior is intentional.

[kazuyukitanimura]

nit: I think parquet.enable.dictionary=false,true is removed everywhere recently

[kazuyukitanimura]

Pending ci (it looks there is a format issue)

[andygrove]

@mbutrovich regarding It might be worth adding Int32 boundary values (2147483647, -2147483648) . Spark itself cannot handle those cases.

Error executing SQL 'SELECT date_from_unix_date(i) FROM test_date_from_unix_date' [EXPRESSION_DECODING_FAILED] Failed to decode a row to a value of the expressions:                     
  createexternalrow(static_invoke(DateTimeUtils.toJavaDate(input[0, date, true])), StructField(date_from_unix_date(i),DateType,true)). SQLSTATE: 42846

[andygrove]

Merged. Thanks @kazuyukitanimura @mbutrovich