viirya opened a new pull request, #26070: URL: https://github.com/apache/datafusion/pull/26070
## Which issue does this PR close? - Closes #25856. ## Rationale for this change `date_bin` accepted negative strides, but they had no defined semantics: - A negative fixed stride rounds toward the origin, so a timestamp before the origin can land in a bin after it. - A negative month stride is not monotonic. `date_bin(INTERVAL '-1 month', ts, TIMESTAMP '2023-01-31')` bins 2023-01-01 to 2023-02-28 and 2023-01-31 to itself. #25815 worked around the second one by not propagating ordering for negative month strides. As discussed in #25856, `date_bin` now rejects strides that are not positive. This matches PostgreSQL for fixed strides (PostgreSQL does not support month strides at all), and DataFusion applies the same rule to month strides. A positive stride already bins timestamps before the origin, so a negative stride adds nothing, and an error is better than silently taking the absolute value of an accidental negative. ## What changes are included in this PR? - `date_bin` returns `DATE_BIN stride must be greater than zero` for a stride that is not positive. This covers negative months, negative days or nanoseconds, intervals whose parts add up to a negative stride, and TIME inputs. The zero-stride error is folded into this message. - `output_ordering` no longer special-cases negative month strides: any constant stride preserves the order of the source. - With only positive strides, `compute_distance` and `compute_distance_wide` round down with `rem_euclid`. For a positive stride this is the same as the old truncate-then-step-back logic, and the two functions still match. Overflow near `i64::MIN` still returns an error, which becomes NULL. - The `date_bin` docs say the interval must be greater than zero, and the 56.0.0 upgrade guide describes the change. ## What is the testing strategy for this PR? - `date_bin_errors.slt`: error cases for negative month, year, minute, day and nanosecond strides, an interval whose parts add up to a negative stride, scalar and column inputs at second and nanosecond precision, and TIME inputs. The `-1 nanosecond` case replaces the unit test for the `i64::MIN % -1` overflow from #22215, which can no longer be reached. - `timestamps.slt`: the negative-month ordering cases from #25815 are replaced by the error tests above. The positive-month control stays, and the zero-stride cases expect the new message. - Unit tests: `test_date_bin` covers negative `IntervalDayTime` strides, which SQL interval literals cannot produce. `output_ordering_requires_constant_stride` replaces `output_ordering_requires_monotonic_stride`. ## Are there any user-facing changes? Yes, this is a breaking change: a negative `date_bin` stride is now an error. Previously it returned the same bins as the positive stride when the source was at or after the origin (for month strides, only when the source's day of month was not earlier than the origin's), and a bin later than the source otherwise. The zero-stride error message also changes. Both are documented in the 56.0.0 upgrade guide. This pull request and its description were written by Isaac. -- 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]
