Fix TIMESTAMP/DATE arithmetic and DATE→TIMESTAMP cast

[vinaykpud]

Description

Two small bugs on the analytics-engine PPL path that crashed any
query touching DATE-typed expressions.

1. TIMESTAMP - TIMESTAMP returns HTTP 400.
PPL lowers t1 - t2 to MINUS(precision_timestamp, precision_timestamp),
but Substrait's default catalog only declares numeric subtract.
Isthmus rejects with:

Unable to convert call -(precision_timestamp<N>?, precision_timestamp<N>?)

Fix: new MinusAdapter rewrites the call as
from_unixtime(to_unixtime(t1) - to_unixtime(t2)) (a TIMESTAMP-typed
result so Calcite's Project type-check holds). Numeric operands pass
through.

2. TIMESTAMP(<date column>) returns HTTP 500.
The DATE column lowers to to_timestamp(date_col), but DataFusion's
to_timestamp UDF doesn't accept Date32:

Unsupported data type Date32 for function to_timestamp

This also blew up TIME = DATE comparisons (the coercion lifts
the DATE side through TIMESTAMP(...)).

Fix: in TimestampFunctionAdapter, when the operand's SQL type
is DATE, emit a native CAST(Date32 → TIMESTAMP) (arrow's
cast_kernel) instead of falling through to the to_timestamp UDF.
Matches Shape B's literal-fold semantics (midnight UTC of the day).

Changes

• MinusAdapter (new) — registered on ScalarFunction.MINUS.
• TimestampFunctionAdapter#tryLiftDateOperand — DATE-column lift.
• MinusAdapterTests (new, 5 tests).
• TimestampFunctionAdapterTests — Shape F split into
  TIMESTAMP-column and DATE-column cases.
• IT coverage in DateTimeScalarFunctionsIT and TimestampFunctionIT.

Check List

• Functionality includes testing.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Possible Issue The adapter always casts the result back to the original call type (line 54), but for DATE-DATE subtraction, PPL semantics may expect an integer day-count (as shown in the IT test at DateTimeScalarFunctionsIT.java:197), not a TIMESTAMP. If the original call type is TIMESTAMP when operands are DATE, the cast will produce a TIMESTAMP instead of the expected integer, breaking the day-count semantics. // PPL's MINUS(DATETIME, DATETIME) infers TIMESTAMP at the call site; lift the // BIGINT seconds back through from_unixtime so Project.isValid type-matches. RelDataType fp64 = rexBuilder.getTypeFactory().createSqlType(SqlTypeName.DOUBLE); RexNode diffDouble = rexBuilder.makeCast(fp64, diffSeconds, true); RexNode asTimestamp = rexBuilder.makeCall(RustUdfDateTimeAdapters.LOCAL_FROM_UNIXTIME_OP, diffDouble); return rexBuilder.makeCast(original.getType(), asTimestamp, true);

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Add null safety for operand types Add null safety checks for operand types before calling getType(). If either operand is null or has a null type, the adapter could throw a NullPointerException. Return the original call early if types are unavailable. sandbox/plugins/analytics-backend-datafusion/src/main/java/org/opensearch/be/datafusion/MinusAdapter.java [38-42] RexNode left = original.getOperands().get(0); RexNode right = original.getOperands().get(1); +if (left.getType() == null || right.getType() == null) { + return original; +} if (!isDateOrTimestamp(left.getType()) || !isDateOrTimestamp(right.getType())) { return original; } Suggestion importance[1-10]: 7 __ Why: Adding null checks for left.getType() and right.getType() prevents potential NullPointerException when operands have null types. This is a defensive programming practice that improves robustness.	Medium
	Add null check for operand type Add a null check for operand.getType() before calling getSqlTypeName(). If the operand type is null after stripping annotations, this will cause a NullPointerException. Return null early if the type is unavailable. sandbox/plugins/analytics-backend-datafusion/src/main/java/org/opensearch/be/datafusion/TimestampFunctionAdapter.java [116-119] RexNode operand = stripOperatorAnnotation(original.getOperands().get(0)); -if (operand.getType().getSqlTypeName() != SqlTypeName.DATE) { +if (operand.getType() == null || operand.getType().getSqlTypeName() != SqlTypeName.DATE) { return null; } Suggestion importance[1-10]: 7 __ Why: Adding a null check for operand.getType() before calling getSqlTypeName() prevents potential NullPointerException. This defensive check improves code robustness when handling edge cases.	Medium
	Clarify unary minus handling The adapter should handle the unary minus operator (negation) explicitly by checking the operand count first. Currently, unary minus passes through correctly, but the logic could be clearer by separating the operator check from the operand count check to avoid confusion. sandbox/plugins/analytics-backend-datafusion/src/main/java/org/opensearch/be/datafusion/MinusAdapter.java [35-37] -if (original.getOperator() != SqlStdOperatorTable.MINUS || original.getOperands().size() != 2) { +if (original.getOperands().size() != 2) { + return original; +} +if (original.getOperator() != SqlStdOperatorTable.MINUS) { return original; } Suggestion importance[1-10]: 3 __ Why: While separating the checks might improve readability slightly, the current implementation is correct and the test testUnaryMinusPassesThrough confirms it works. The improvement is marginal and mostly stylistic.	Low

[github-actions]

✅ Gradle check result for 23167b7: SUCCESS

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.44%. Comparing base (0755be0) to head (23167b7).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #21978      +/-   ##
============================================
+ Coverage     73.43%   73.44%   +0.01%     
- Complexity    75515    75555      +40     
============================================
  Files          6037     6037              
  Lines        342786   342786              
  Branches      49311    49311              
============================================
+ Hits         251723   251759      +36     
- Misses        71046    71050       +4     
+ Partials      20017    19977      -40     

☔ View full report in Codecov by Harness.
📢 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.