BUG: Timestamp origin takes no effect in resample for 'MS' frequency

[mcgeestocks]

• closes BUG: Timestamp origin takes no effect in resample for 'MS' frequency #53662
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

[mcgeestocks]

It seems the _get_timestamp_range_edges() never accounted for the edge case involving a combination of a DateTimeLike origin and a freq.

The change adds a simple check to modify the way the range is set ( first - freq ) vs ( freq.rollback() ) depending on the inputs.

This gives the behaviour you're after @MarcoGorelli and preserves all other functionality.
Let me know if I'm missing anything.

[MarcoGorelli]

thanks for your pr - this looks a bit complex, but it's encouraging that tests pass - I'll check next week!

[mcgeestocks]

thanks for your pr - this looks a bit complex, but it's encouraging that tests pass - I'll check next week!

Hey @MarcoGorelli just bumping this up.

[MarcoGorelli]

Thanks for your PR

Does this always work? For example, if we have

In [39]: df = pd.DataFrame({'ts': [datetime(1999, 12, 31, 20)], 'values': [10.]})

In [40]: df
Out[40]:
                   ts  values
0 1999-12-31 20:00:00    10.0

and do

df.resample('3YS', on='ts', closed='left', label='left', origin=datetime(1995, 1, 1))['values'].sum()

then I'd expect the windows to be:

• [1995-01-01, 1998-01-01)
• [1998-01-01, 2001-01-01)

But instead, I see:

In [42]: df.resample('3YS', on='ts', closed='left', label='left', origin=datetime(1995, 1, 1))['values'].sum()
Out[42]:
ts
1999-01-01    10.0
Freq: 3AS-JAN, Name: values, dtype: float64

[mcgeestocks]

I'll need to switch approaches. My solution only covers cases where the origin is within the period specified.

[MarcoGorelli]

could always raise an error if it's not, we don't need to do 4-D gymnastics, the most important thing is that for the cases when the computation succeeds, it's correct

[mcgeestocks]

Alright @MarcoGorelli I updated what I was doing to be a bit more straightforward.
Now when the origin is a timestamp it's taken into account when setting timestamp_range_edges during resampling.
I also had to update a few test to account for the desired behavior.

[mcgeestocks]

Looks like I also need to update the Docs with the new expected behavior

[MarcoGorelli]

For tz-naive, this seems correct. Nice one!

I think we just need some extra care for the tz-aware case

[mcgeestocks]

For tz-naive, this seems correct. Nice one!

I think we just need some extra care for the tz-aware case

Added a check on the equality of Daylight Savings Time via dst. All checks pass including your proposed edge case.
I believe everything else is taken care of.

[MarcoGorelli]

thanks for updating - this looks close 💪

[mcgeestocks]

Anything else you want to see here @MarcoGorelli?

[MarcoGorelli]

this is probably fine - will take a (hopefully final) look tomorrow

[MarcoGorelli]

Nice, great work here

Leaving open a little in case anyone has objections, but I think this should go in for 2.1