Seasons Definition - Best Practice

Hi all,

I was wondering what others do / consider best practice for definition of seasons within intervals.icu for comparing against previous bests / training load etc (on the /power, /fitness, /compare, /totals pages for instance).

I have tended to simply have a season per year, but am thinking perhaps that is not the best thing to do. For instance at this end of the year my power bests and training load are down compared to my bests during the Summer (Northern Hemisphere-er here!), so comparison there is of no real benefit. And come January 1st, it doesn’t really make sense to zero everything as my January efforts will be of interest compared against my recent end-of-year efforts.

I’m thinking it may be better to set up e.g Summer & Winter seasons to compare easier the type of training that I am doing. Perhaps aligned to Spring & Autumn equinoxes? Which would be season changeover at end of March & end of September. But then I may still put some good efforts in during October with the last of my Summer form… so maybe would be better to have unequal length seasons, e.g November - March (5 month winter season) & April - October (7 month summer season). And that would align with clock changes for daylight savings…

What do you do / think is best?

1 Like

On a related note I do have “season match” functionality on the todo list i.e. comparing how you are doing now compared to the same number of days into last season.

4 Likes

Is their any news on the season match functionality?

Not yet :frowning:

I have been busy with a lot of data migrations and devops work but thats all coming to an end now. So I should be able to crank out features a bit quicker now.

@david,

To your seasons backlog, can I add the ability when defining a season to pick the end date? That is, I should be able to define arbitrary “seasons” that overlap.

Unfortunately thats very difficult to do. There is lots of code in Intervals.icu that assumes seasons don’t overlap.