viirya commented on code in PR #25815:
URL: https://github.com/apache/datafusion/pull/25815#discussion_r4159165469
##########
datafusion/functions/src/datetime/date_bin.rs:
##########
@@ -475,11 +562,31 @@ fn date_bin_timestamp_value<T: ArrowTimestampType>(
value: i64,
origin: i64,
stride: i64,
- stride_fn: BinFunction,
+ stride_fn: BinFunctions,
) -> Option<i64> {
let scale = timestamp_scale::<T>();
- scale_and_bin_to_nanos(value, scale, origin, stride, stride_fn)
- .map(|binned| binned / scale)
+ match scale_and_bin_to_nanos(value, scale, origin, stride,
stride_fn.narrow) {
+ Some(binned) => Some(binned / scale),
+ None => {
+ date_bin_timestamp_value_wide(value, scale, origin, stride,
stride_fn.wide)
+ }
+ }
+}
+
+// Slow path for values whose i64 nanosecond computation overflows. Binning in
+// i128 means that only a result outside the source type's range becomes NULL,
+// instead of any value outside the i64 nanosecond range.
Review Comment:
Yes, exactly: with a positive stride the bin is never after its source, so
at the high end it always fits; it's only that going through chrono we can't
compute it. That's what #25855 is about. Once the month arithmetic no longer
uses chrono, that case goes away entirely, so I don't think we need an error
for it. If #25855 stalls, erroring would be a reasonable stopgap.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
