rok commented on PR #12657: URL: https://github.com/apache/arrow/pull/12657#issuecomment-1141417140
> There was the issue about `calendar_based_origin=True` potentially breaking sortedness (as discussed in #12528). > > Are we fine with this caveat? Maybe yes, since it is also what lubridate does (but mention it in the docs?). Or would it be possible to guard the user from that ever happening? I think we're ok with `calendar_based_origin=True` breaking sortedness as it would be an explicitly chosen way of rounding for users outside of lubridate. I'll add a note about this to docs. We could also introduce `perserve_sortedness` flag in #12528 and handle `calendar_based_origin=True` case. > For example, if you round by "x" minutes, the origin unit is an hour, and in that case we could error if one hour is not dividable by "x"? Although for hours and below that can work, but I suppose for days, months, years that is not possible? Lubridate actually limits to time multiples smaller or equal than the greater time unit - e.g. "61min" is not a valid rounding, but "60min" is. Your proposal makes things safer but we might want to "deregulate" it later. Leaving things as is gives more options but we might need to limit them later. Dunno, I don't have an opinion on this. -- 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: github-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
