mhilton commented on code in PR #25815:
URL: https://github.com/apache/datafusion/pull/25815#discussion_r4153776681
##########
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:
I wonder if it would be better to preserve the ordering here by converting
to `i64::MIN` rather than `NULL`. Although that might be a technically wrong
result I'm not sure that it's any less helpful than a `NULL`. We'd have to
document that this is what `date_bin` does, but seeing as those dates are so
far in the past I don't think it will cause a practical issue. Even when using
nanoseconds we are discussing a time bin at some point in 1677.
--
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]
