DOC: Clarify DST rounding behavior in Timestamp/DatetimeIndex

[mroeschke]

xref #44287

• Ensure all linting tests pass, see here for how to run them

[jreback]

just wondering out loud if we could/should actually do this in a tz-aware way for .round, .ceil, .floor; e.g. are these fundamentally different ops that say subtraction that we could always do this w/o going ambiguous

cc @mroeschke

[mroeschke]

@jreback found discussion #22560 (comment) and #22560 (comment) that rounding in a tz-aware might not actually be possible and falling back to rounding based on actual, UTC time may give unexpected results.

[jreback]

my question is can we leave in thr tz and do a round operation w/o introducing ambiguity?

[mroeschke]

Hmm since the rounding operations happen on epoch timestamps, rounding could happen on the UTC epoch timestamps and relocalized without ambiguity i.e. .tz_convert("UTC").round(...).tz_convert(tz). But this flies counter to #22560 (comment) and the notion of "round relative to the wall time"

[jreback]

@mroeschke rereading i am wondering if it's always possible in freq < day (eg hour / min) to do the round ops in local time (and not convert-round-localize) which can introduce ambiguity

[mroeschke]

Yeah for small rounding frequencies this can be achieved. Looking at the UTC offsets I think the limit is sub 15 minutes (I see a +05:45 UTC offset for example)

[jreback]

thanks @mroeschke