API: offsets.Day should be one calendar day instead of 24 hours

[mroeschke]

xref issues

• Troubles with date_range and DST #20596
• API: Wrong DateOffset behaviour with DST changes #16980
• 'date_range' no longer has a true "24H" frequency #8774

As I understand the offset classes, they are supposed to respect transitions in "wall time" instead of absolute time. Currently the Day offset is currently defined to be 24 hours instead of 1 calendar day which is problematic to respect "wall time" wrt DST transitions.

In [25]: foo
Out[25]: Timestamp('2016-10-30 00:00:00+0300', tz='Europe/Helsinki') # DST change on this day

In [26]: foo + pd.tseries.offsets.DateOffset(weeks=1)
Out[26]: Timestamp('2016-11-06 00:00:00+0200', tz='Europe/Helsinki')

In [27]: foo + pd.tseries.offsets.Week()
Out[27]: Timestamp('2016-11-06 00:00:00+0200', tz='Europe/Helsinki') # respects calendar transition

In [28]: foo + pd.Timedelta(weeks=1)
Out[28]: Timestamp('2016-11-05 23:00:00+0200', tz='Europe/Helsinki')

In [29]: foo + pd.tseries.offsets.DateOffset(days=1)
Out[29]: Timestamp('2016-10-31 00:00:00+0200', tz='Europe/Helsinki')

In [30]: foo + pd.tseries.offsets.Day()
Out[30]: Timestamp('2016-10-30 23:00:00+0200', tz='Europe/Helsinki') # does not respects calendar transition

In [31]: foo + pd.Timedelta(days=1)
Out[31]: Timestamp('2016-10-30 23:00:00+0200', tz='Europe/Helsinki')

From prior issues, #20596, #16980, #8774, it seems like many are confused that 1 day = 24 hours when the DST transition comes up and defining 1 day = 1 calendar day would be more intuitive and consistent with other offsets. @

[jbrockmendel]

+1. As it is, Ticks are all redundant with Timedeltas.

[jreback]

@mroeschke happy for you to have a look at the implications of changing this. i consolidated the other issues to this one.

[mroeschke]

So currently Day (and smaller freq resolutions) are subclassed from Tick (which subclasses from DateOffset) instead of directly subclassing from DateOffset like other offsets. I think the easiest path for gaining (intuitive) consistency between offsets is to have Day directly from DateOffset.

It appears the main reason why Tick was created was to have a separate path for ops compared to DateOffsets (which creates this confusing behavior), but is there another reason (historical or other feature) why Day should still subclass from Tick?

[jbrockmendel]

I can't speak to the historical reasons for the design, but I know that the Tick classes have much more performant implementations of a number of methods.

The easiest way to change the behavior to that suggested by the OP is to add the line _adjust_dst = True to the Day class.

[mroeschke]

Thanks for the tip @jbrockmendel; good enough reason to keep Tick around. I'll start exploring that avenue then.