Change integers for season_peak and season_trough

[robjhyndman]

These current take values 0:(m-1). It would be much easier to interpret if they took 1:m by changing 0 to m and leaving the others as they are. See https://otexts.com/fpp3/exploring-australian-tourism-data.html where we have had to modify it to get an interpretable graph.

[mitchelloharawild]

Ideally this would give you a year-less unit, much like https://github.com/r-lib/clock/issues/61 as this would allow us to embed the "quarter" component to this. I don't know of an established data structure for this type of data yet, but I'm hoping {clock} will be suitable ({moment} was partially created for this type of problem also).

I think the right approach for this is to provide more information to the feature methods (specifically the data's index). Currently the value is relative to the starting time within the seasonal period. I don't want to offset it to 1:m because this could mislead users into thinking that 1 is always "Q1".

edit: However if/when features() is updated to provide additional info like the index, making this analysis easier would be possible.

[robjhyndman]

Actually I think 1 should always be Q1 for quarterly data. So with monthly data, if the first month in the data set is February, and the seasonal peak is March, then it should take season_peak_year=3.

[mitchelloharawild]

Yes, this is what I would like also. To make this possible, we need features(<tsibble>) to provide the index variable to feature functions where necessary.

In combination with potential improvements in time/date classes ({clock} :crossed_fingers:), this would allow us to provide season_peak_year=Q1 or season_peak_year=March to eliminate all confusion. Here Q1 and March are continuous, year-less, time variables which can be promoted to year-quarter or year-month variables by setting the year.