[MNT] Adress pandas deprecation of `M` frequency in datetimeindexes about sktime HOT 8 OPEN

@fkiraly @yarnabrina I think this is strongly related to how our forecasting horizon is implemented. Since this warning is often raised in _fh.py line 415 and _fh.py line 172. A test that triggers this warning is: test_hierarchical_with_exogeneous

I think we have several options here:

• Remove the frequency from our forecasting horizon
• Support only PeriodAliases -> to_absolute would return PeriodIndex like
• Support only Frequencies -> to_absolute would return DatetimeIndex like
• Try to support both and handle it flexible
• Try to just fix it for now

I am currently in favor for a more general solution than just a fix. Since I suppose that a simple fix would just increase the code complexity and we had this discussion about reworking the ForecastnigHorizon several times.

from sktime.

I am currently in favor for a more general solution than just a fix.

Strongly agreed.

Remove the frequency from our forecasting horizon

Assuming this means using range index for everything and not use the dates in the dataset, I'll be in favour of that. I am practically using the same myself in office work and managing dates to indices conversion myself.

(It will cause problem in generating dates for future though, so that will be the tricky part to reduce breaking changes I think.)

from sktime.

Assuming this means using range index for everything and not use the dates in the dataset, I'll be in favour of that.

I'd be against that, handling irregularly spaced time series is an important feature for some of our users.

I'd be in favour of decoupling the ForecastingHorizon as much as possible from pandas frequency handling, e.g., use range or float index internally and do conversions in input and output points.

Possibly, internally everything we currently support is convertible to int:

• periods by mapping to "period since" convention
• time stamps by mapping to the internal integer that it uses anyway

from sktime.

use range or float index internally and do conversions in input and output points

May be I am missing something, but in my brain this is exactly same as what I assumed above.

from sktime.

May be I am missing something, but in my brain this is exactly same as what I assumed above.

Perhaps - in your mental model, in the end design, is ForecastingHorizon able to produce datetime and period indices with freq, e.g., in to_absolute?

from sktime.

@fkiraly you are referring to a IntIndex not RangeIndex internally or?

from sktime.

yes, because RangeIndex is always contiguous. Imo one needs to be able to represent sth like 0, 1, 2, 3, 5, etc as well, for irregularly spaced series or horizons.

from sktime.

@benHeid, @yarnabrina, do we have a plan on how to address this? Any suggestions?

from sktime.