jorisvandenbossche commented on PR #12528: URL: https://github.com/apache/arrow/pull/12528#issuecomment-1131528343
Ah, indeed (I was assuming that in case of 16min it doesn't matter because a day is divisible in 16 min parts, so if you start to count from the start of that day or not doesn't matter. But the "higher" calendar item for minute is of course hour and not day ..) Using the branch from https://github.com/apache/arrow/pull/12657 (and using naive times) shows this: ``` In [5]: arr = pa.array(["2015-03-29 01:50:00", "2015-03-29 01:59:59", "2015-03-29 03:00:00", "2015-03-29 03:10:00"]).cast(pa.timestamp("us")) In [6]: arr Out[6]: <pyarrow.lib.TimestampArray object at 0x7f40eb249ee0> [ 2015-03-29 01:50:00.000000, 2015-03-29 01:59:59.000000, 2015-03-29 03:00:00.000000, 2015-03-29 03:10:00.000000 ] In [7]: pc.round_temporal(arr, 16, "minute") Out[7]: <pyarrow.lib.TimestampArray object at 0x7f40ea1ce7c0> [ 2015-03-29 01:52:00.000000, 2015-03-29 01:52:00.000000, 2015-03-29 02:56:00.000000, 2015-03-29 03:12:00.000000 ] In [8]: pc.round_temporal(arr, 16, "minute", calendar_based_origin=True) Out[8]: <pyarrow.lib.TimestampArray object at 0x7f40ea1ce700> [ 2015-03-29 01:48:00.000000, 2015-03-29 02:04:00.000000, 2015-03-29 03:00:00.000000, 2015-03-29 03:16:00.000000 ] ``` Although I would say that the second result value "02:04:00" seems off? (if it should start to count from the hour, it should either be "02:00" or "02:16"; but in this case it is still counting from the hour before ("01:00" + 4*16 min)) But that is something for the other PR (and actually consistent with lubridate ..) -- 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]
