ThilakShekharShriyan opened a new pull request, #26153:
URL: https://github.com/apache/datafusion/pull/26153

   ## Which issue does this PR close?
   
   Closes #25855.
   
   ## Rationale for this change
   
   `date_bin` with a month stride returned `NULL` for timestamps that sit 
outside `DateTime<Utc>`, even when the month start still fits in the output 
type. Second, millisecond, and microsecond timestamps can be wider than 
chrono's range. A month bin should be `NULL` only when that bin itself does not 
fit.
   
   ## What changes are included in this PR?
   
   The narrow month path is unchanged and still uses chrono for timestamps that 
fit in `i64` nanoseconds.
   
   The wide path, used when the nanosecond conversion overflows, now bins on 
the civil calendar with the same day-count conversion `date_trunc` already 
uses. It keeps the existing stride rule, including negative strides, and clamps 
a missing day to the end of the month the way `checked_add_months` does. When 
the candidate is after the source, it steps back one stride from the origin 
rather than from the already-clamped date.
   
   A result that does not fit the output unit is still `NULL`. That covers 
`Timestamp(Second)::MIN` and a nanosecond source with a stride too large for 
`i64` nanoseconds.
   
   ## What is the testing strategy for this PR?
   
   - `date_bin_errors.slt` covers the issue: `10_000_000_000_000` seconds bins 
to month start `9999998294400`, and the negative input bins to 
`-10000001059200`.
   - The same file updates the large millisecond stride from issue #20219. That 
bin fits in milliseconds (`-4306016287785600000`) and used to be `NULL` only 
because chrono overflowed. The nanosecond form of that stride still expects 
`NULL`.
   - A unit test checks that the wide path matches the chrono path for in-range 
values, including month-end clamping, a leap day, negative strides, and dates 
before the epoch.
   
   ## Are there any user-facing changes?
   
   Yes. Month-stride `date_bin` now returns the month start for timestamps 
outside chrono's range when that instant fits the output type. Values that 
already fit in `i64` nanoseconds are unchanged. No public API change.
   
   Made with [Cursor](https://cursor.com)


-- 
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]

Reply via email to