rok commented on PR #12528: URL: https://github.com/apache/arrow/pull/12528#issuecomment-1131567401
> But also in general, the question is: _what is actually the expected / desired result in the first place?_ Because the first and third value end up as "01:52:00+01:00" and "01:56:00+01:00" after rounding. But those two values are only 4 min apart, while the rounding was by 16min. So you would expect that every possible value in the result is 16min apart from each other. > > I think this comes back to: do we want to result to be rounded in "physical time" (so the results are actually 16 min apart), or in "wall clock time"? Generally we round in local wall clock time, but when there are DST jumps, that will then cause times that are not actually the rounding unit apart from each other (only in case the rounding unit is not an exact divider of the DST jump, like the 16min here). Because of DST jumps pretty calendar rounding in wall time is impossible without having two "correction intervals" a year. If a user wants physical time rounding they can still fall back to `round(utc_time + offset) - offset`. I don't know much about user expectations beyond precedents by Pandas and lubridate, but we should probably have idempotency, maintain sortedness of "timestamp continuum" in UTC and maintain sortedness in local time. That might constrain the problem enough to only have one solution? :) Also inside a DST jump we can choose to align the start or the end of the jump with the rounding outside of the jump. Right now we (I think) make this choice based on basis of wether we're doing a ceil or a floor. My worry here is this might not preserve the sortnedness (e.g. flooring to 16 minutes will in some cases floor to 4minutes before the start of a DST jump). -- 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]
