Unify timeindex used in eTraGo in eDisGo

[ClaraBuettner]

eTraGo and eDisGo are currently using different years for the timeindex.
For eGon2035, eTraGo uses 2011 (the weather and calendar-year) and eDisGo is using 2035 (the scenario year).
This makes it a bit complicated to hand over data from eTraGo to eDisGo. In addition, it can be confusing for users.
So I would prefer to agree on one timeindex year and adjust it accordingly, at least for the scenarios we will create in the future.

[ClaraBuettner]

We agreed on using the future year as a timeindex today

[ClaraBuettner]

I had a look at etrago, it seems to be quite easy to adjust the time index there.

But thinking about it again, I am a bit concerned that it creates problems when our future year is a leap year but the weather year is not (and vice versa).
In addition, there is also the problem to identify week days that we discussed.
So I am wondering if it would be more consistent to stick to the calendar/weather year in the time index.
We could remove the year from our existing plots (since it would be the same one anyhow) and document that the calendar/weather year of the scenario is used.

[KathiEsterl]

@MoritzSchloesser, @ClaraBuettner, and I discussed this issue again this morning. We propose to keep 2011 as time index due to the multiple conversion conflicts and the reasons outlined above. We also believe this approach will make it easier to handle future scenarios.

Any necessary adaptations can still be implemented in the graphs and analyses if needed, but these would be optional.

@joda9 Would this be okay with you?

[KathiEsterl]

Needs to be adapted within eDisGo: eDisGo needs to load the corresponding weather and calendar year and apply it to all timeseries data.

Could involve quite some more work and risks - so probably could also be moved to the later Release (0.4.1).

@MoritzSchloesser, @ClaraBuettner, and I discussed this issue again this morning. We propose to keep 2011 as time index due to the multiple conversion conflicts and the reasons outlined above. We also believe this approach will make it easier to handle future scenarios.

Any necessary adaptations can still be implemented in the graphs and analyses if needed, but these would be optional.

@joda9 Would this be okay with you?