GH-37377: [C#] Throw OverflowException on overflow in TimestampArray.ConvertTo()

[DanTm99]

Throw OverflowException on overflow in TimestampArray.ConvertTo() when DataType.Unit is Nanosecond and ticks is large, instead of silently overflowing and returning the wrong value.

• Closes: [C#] TimestampArray.ConvertTo() returns erroneous value for large ticks when returning nanoseconds #37377

[github-actions]

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

[DanTm99]

@westonpace

[westonpace]

I think I could go either way on this. Timestamps are int64 and so I wouldn't expect this overflow to be a frequent occurrence. Also, this ConvertTo could be on the hot loop for something doing a lot of array building.

@CurtHagenlocher , do you have an opinion?

[CurtHagenlocher]

I also could go either way. It's hard to predict the kind of scenarios that people might care about but I think the lower precision of DateTime vs nanos makes it a suboptimal fit anyway. Users who need the performance could do the conversion on the outside and then use the overload for appending an int64 directly.

That said, there are other places in the code where multiplication happens e.g. GetTimestampUnchecked (for a different meaning of "unchecked") and I don't know how to describe a policy for when these should be checked and when they shouldn't be.

[westonpace]

Ok, let's proceed to merge. If we need fast paths in C# we can add them later or use the int64 path.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 5 benchmarking runs that have been run so far on merge-commit 2864870.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.