GH-50395: [C++] Support duration inputs in temporal rounding

[snigdhachoppac]

Rationale for this change

The ceil_temporal, floor_temporal, and round_temporal functions currently support date, time, and timestamp inputs, but not duration inputs.

What changes are included in this PR?

• Add kernel registration for duration values with second, millisecond, microsecond, and nanosecond resolutions
• Support rounding duration inputs using physical units through day
• Treat week as seven physical days for duration inputs
• Reject ambiguous calendar units such as month, quarter, and year
• Reject calendar_based_origin for duration inputs
• Add focused C++ tests covering all four duration resolutions, positive and negative values, null propagation, day and week rounding, and unsupported calendar behavior

Are these changes tested?

Yes.

• arrow-compute-scalar-temporal-test: 55 tests passed
• Applicable pre-commit C++ formatting and lint checks passed

Are there any user-facing changes?

Yes. Users can now pass duration values to ceil_temporal, floor_temporal, and round_temporal for supported physical units.

AI assistance

I used ChatGPT to help navigate the codebase and draft the initial implementation. I reviewed, revised, and tested the changes locally.

• GitHub Issue: [C++] Support duration type in floor_temporal/etc #50395

[github-actions]

⚠️ GitHub issue #50395 has been automatically assigned in GitHub to PR creator.

[rok]

Thanks for opening this @snigdhachoppac.

While these tests look visually ok, but I'd like to have a deeper verification of correctness. Could you please add a pandas integration tests in test_compute.py? See test_round_temporal as an example.

Thank you for sharing this PR was at least in part generated with ChatGPT.
Feel free to say no to this request: could you please share prompts you used to generate this PR? As a project we're dealing with a large inflow of generated PRs we have to triage and review and knowing which prompts were used to generate them could help us review said PR.

[rok]

Did you check values in these tests manually?

[snigdhachoppac]

I derived them from fixed-duration semantics and the existing tie-breaking behavior, but I’ll independently verify each expected value while updating the tests.

[rok]

There is a lot of downstream users that will potentially use this functionality. We want to be as sure about these as possible. So derived + human review + agent review would be great.

[snigdhachoppac]

I manually re-derived the expected values using fixed-duration boundaries, including negative values and halfway cases. I also added a pandas integration test that independently compares Arrow’s results against pandas for nanoseconds, microseconds, milliseconds, seconds, minutes, hours, days, and weeks. All 8 parameterized integration cases and the full 55-test C++ temporal suite pass locally.

[rok]

A philosophical question perhaps: how can verify that you, the physical person, did manually verify these and it's not just your agent trying to convince me?

[snigdhachoppac]

Thanks for the review. I’ll add the pandas integration test, expand the C++ coverage to minutes and hours, and re-check the expected values before pushing an update.

I mainly used ChatGPT for codebase navigation, debugging, and drafting an initial test structure. I inspected the relevant implementation, adjusted the scope based on the issue discussion, reviewed the changes, and ran the targeted and full test suites locally. Some prompts I used include:
“Where are ceil_temporal, floor_temporal, and round_temporal registered in Arrow?”
“How are duration types represented in the C++ compute kernels?”
“Can you help me interpret this build/test failure and identify the relevant test target?”

[snigdhachoppac]

I pushed the requested updates with explicit minute/hour C++ coverage and a pandas integration test modeled after test_round_temporal. The full C++ temporal suite passes with 55 tests, and all 8 pandas integration cases pass.

[rok]

@pitrou is assigning multiple here ok?

[pitrou]

Hmm, probably? There is a slight risk of overflow and we may want to guard for that, but that sounds extremely unlikely as well.

[rok]

@snigdhachoppac could you add an overflow guard such as this one?

arrow/cpp/src/arrow/extension/tensor_internal.cc

Lines 48 to 54 in 2ae036f

	int64_t product = 1;
	for (const auto dim : shape) {
	if (MultiplyWithOverflow(product, dim, &product)) {
	return Status::Invalid(
	"Product of tensor shape dimensions would not fit in 64-bit integer");
	}
	}

[snigdhachoppac]

Added a checked multiplication using MultiplyWithOverflow before converting week multiples to days, along with regression coverage for ceil_temporal, floor_temporal, and round_temporal. The targeted tests, full 56-test temporal C++ suite, and pandas integration tests pass locally.

[rok]

As far as I'm concerned this PR could be merged, but I would like a second review. @pitrou could you take a look please?