DX-105463: [C++][Gandiva] Add TimestampIR wrapper for next_day

[akravchukdremio]

Summary

Fixes a silent-wrong-results correctness bug in next_day(timestamp[us/ns], utf8) when the relaxed DataTypeEquals routes non-ms timestamps through Gandiva but no IR wrapper exists.

Follow-up to #134 (TimestampIR for unit-aware timestamp support, now merged).

Background

During end-to-end testing of #134 against real Parquet/Iceberg data (which stores timestamps as timestamp[us] regardless of the original SQL precision), NEXT_DAY(ts_us, 'MO') returned +53425-02-28 — a date ~51,000 years in the future — instead of the correct Monday after the input date.

Root cause

next_day is registered in function_registry_datetime.cc for both date64 and timestamp via the DATE_TYPES macro:

DATE_TYPES(NEXT_DAY_SAFE_NULL_IF_NULL, next_day, {})

But next_day was not included in any of the static tables in timestamp_ir.cc (kExtracts, kTruncs, kDiffs, kCastsFromTs, kDateArithEntries, kFixedAdds, kCalendarAdds). As a result, no next_day_from_timestamp_us / _ns IR wrappers were generated.

With the DataTypeEquals relaxation from #134, the validation step matches timestamp[us] against the registered timestamp[ms] signature. BuildFunctionCall then tries to remap next_day_from_timestamp → next_day_from_timestamp_us, fails to find it in IsTimestampIRFunction, and silently falls through to calling the precompiled millis function with raw microsecond values — yielding dates far in the future.

Fix

Adds a BuildNextDayWrapper that follows the cast-from-timestamp pattern:

next_day_from_timestamp_us(ctx, ts_us, day_str, day_len) -> date64 {
  millis = FloorDiv(ts_us, 1000)
  return next_day_from_timestamp(ctx, millis, day_str, day_len)
}

No remainder recombination is needed because next_day returns date64 (midnight of the next weekday), so sub-millisecond input precision is not meaningful in the result.

Files changed

• cpp/src/gandiva/timestamp_ir.h — declare BuildNextDayWrapper
• cpp/src/gandiva/timestamp_ir.cc —
  • Register next_day_from_timestamp{_us,_ns} in BuildAllFunctionNames
  • Implement BuildNextDayWrapper (modeled after BuildCastFromTimestampWrapper with extra context/string/length args)
  • Call it from AddFunctions for each non-ms unit

Build artifacts

Native library built and published with this fix:

• arrow-java release: https://github.com/dremio/arrow-java/releases/tag/v18.3.0-5d2c1e7-73313a7
• GitHub Actions build run: https://github.com/dremio/arrow-java/actions/runs/24584277730
• Jenkins gandiva build: https://jenkins.drem.io/job/custom-arrow-gandiva-build/1536/console
• Maven artifact version: 18.3.0-20260418002220-5d2c1e7-73313a7-dremio

Testing

Verified end-to-end on a local Dremio instance reading Parquet timestamp data.

Test query:

SELECT NEXT_DAY(ts_us, 'MO') FROM tst.dremio_ts_test;

where ts_us is a timestamp[us] column containing 2021-06-15 14:30:45.123456 (a Tuesday).

Before fix (arrow-gandiva 18.3.0-...-28932a0-dremio):

+53425-02-28

(microseconds interpreted as milliseconds → date ~51,000 years in the future)

After fix (arrow-gandiva 18.3.0-...-73313a7-dremio):

2021-06-21

(correct Monday after 2021-06-15)

Are there user-facing changes?

No API changes. NEXT_DAY on TIMESTAMP(6) / TIMESTAMP(9) columns now returns correct results instead of dates ~51,000 years in the future.

🤖 Generated with Claude Code