This doesn't match the PR title, and time makes more sense than duration as a result right?

Also, in that case, we need to validate that the result is not <0 or >=24h (see #12014).

Yeah switching to subtract(time32/64, duration) -> time32/64. I suppose validation should a be part of the subtract kernel then.

Added the validation. Still needs tests.

Added tests.

IMO, it doesn't make sense to cast time to duration.

Indeed. Removed.

nit, but is there any advantage to using the type matcher + computed output type vs the literal types?

Good point!

Since we could subtract a negative duration, we should also check if the output is larger than the maximum acceptable value.

Alternatively - maybe this arithmetic should wrap around? Does that make any sense?

Huh. I wonder how expected this would be. But you're proposing something like this:

if (result < 0) {
  result = result % multiple;
}

Correct?

Right. Though, I'm not sure if that really makes any sense to have.

It feels semantically correct but I'm going to check what Pandas and others do to see what conventions are.

I poked around stdlib datetime but it doesn't seem to implement this. However, I still think we need to check whether the result is in range on both ends.

I found this reference: https://bugs.python.org/issue1487389#msg54803

I think raising an error is OK. If we need wrap-around, we can add that as a separate kernel perhaps.

We should still raise an error if the result is >24:00 though.

Thanks for looking into this! Pandas appears delegate time to Python and rather work with timedelta which is like our duration.
I made this raise on time < 0 and time >= 24:00. Lets revisit if/when desired.

I found this reference: https://bugs.python.org/issue1487389#msg54803

I think raising an error is OK. If we need wrap-around, we can add that as a separate kernel perhaps.

We should still raise an error if the result is >24:00 though.