Pandas version checks
-
[x] I have checked that this issue has not already been reported.
-
[x] I have confirmed this bug exists on the latest version of pandas.
-
[ ] I have confirmed this bug exists on the main branch of pandas.
Reproducible Example
import pandas as pd
s1 = pd.Series(1, pd.date_range('2025', freq='D', periods=700)).resample('2QS-JAN').sum()
s2 = pd.Series(1, pd.date_range('2025-04', freq='D', periods=700)).resample('2QS-JAN').sum()
# s1 expectedly has timestamps in january and july
# s1
# 2025-01-01 181
# 2025-07-01 184
# 2026-01-01 181
# 2026-07-01 154
# Freq: 2QS-JAN, dtype: int64 # NB frequency
# but s2 unexpectedly has timestamps in april and october
# s2
# 2025-04-01 183
# 2025-10-01 182
# 2026-04-01 183
# 2026-10-01 152
# Freq: 2QS-JAN, dtype: int64 # NB frequency
s1.index.freq == s2.index.freq # True
Issue Description
It seems there is no way to force where the period boundaries are when resampling at the 2-Quarter frequency. Resampling at 2QS-APR
gives the same results for s1
and s2
as those shown above.
Expected Behavior
I'd expect the index of s2
to also have timestamps on the first of January and July.
Installed Versions
Comment From: sonuasif748
.
Comment From: rhshadrach
Thanks for the report, I don't think the expectation is correct. It appears to me pandas consistently resamples based on the first observation.
s = pd.Series(1, pd.date_range('2025-04-04', freq='D', periods=5))
print(s)
# 2025-04-02 1
# 2025-04-03 1
# 2025-04-04 1
# 2025-04-05 1
# 2025-04-06 1
print(s.resample('3D').sum())
# 2025-04-02 3
# 2025-04-05 2
# Freq: 3D, dtype: int64
As such, in your example, the first observation for s2
is in the April quarter, and pandas goes every 2-quarters from there on.
You can control this for certain frequencies with origin
, but it has no effect for quarters. It's not clear to me if that's because we cannot support it (e.g. it's ambiguous in certain cases), do not desire to support it (e.g. complexity), or just don't yet. Further investigations are welcome!
Comment From: snitish
@rhshadrach we currently have a QuarterBegin
offset where we can specify the starting month. Would adding a new HalfYearBegin
offset, with a customizable starting month, solve OP's issue? It should be relatively simple to achieve this imo.
Comment From: snitish
Perhaps it's not a bad idea to add HalfYear
offsets in general given we have Quarter
and Year
based offsets.
Comment From: rhshadrach
I'm positive on this, especially if it is a simple addition.
Comment From: snitish
take