Calendar conversion

[aulemahal]

Pull Request Checklist:

• This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes #xyz
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)
• HISTORY.rst has been updated (with summary of main changes)
• bumpversion (minor / major / patch) has been called on this branch
• Tags have been pushed (git push --tags)

• What kind of change does this PR introduce?

Adds the new convert_calendar and interp_calendar methods (and some other utilities) to xclim.core.calendar to help in conversion of data between calendars.

convert_calendar simply modifies the type of the timestamps, not touching the data, unless invalid dates are found (like 29th of Feb on a "noleap" cal). In that case the timeslices (and data) are simply removed. This goes in the sense of #419 as it is completely agnostic of the data frequency.

interp_calendar interpolates the data while converting to the new calendar. While the other accepts named calendars, this one needs the target time coordinate. Interpolation is made on the "decimal year" basis, so the decimal number representing the date as a number of years since 1-01-01 AD. As such, it only gives something useful with daily data or coarser.

• Does this PR introduce a breaking change?

Yes, I only kept references to calendars available in cftime (+ 'standard'). So I removed "no_leap" (use "noleap") and "uniform30day" (use "360_day").

• Other information:

[coveralls]

Pull Request Test Coverage Report for Build 1788

• 80 of 86 (93.02%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.1%) to 89.618%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
xclim/core/calendar.py	80	86	93.02%

Totals
Change from base Build 1766:	0.1%
Covered Lines:	2348
Relevant Lines:	2620

---

💛 - Coveralls

[aulemahal]

@Zeitsperre Working on the xarray failures this morning. Unless you already had some insight on them? Also any idea on the "connection failures" ones?

[aulemahal]

xarray@master is failing because of pydata/xarray#4009, not our fault!

[tlogan2000]

Should I start with this before sdba?

[aulemahal]

@tlogan2000 Yes! If this is ok, I would like to use it in sdba. Anyway, I don't think it be safe to merge sdba before the next release of xarray...

[huard]

I think this will need additional documentation to clarify the options to drop and add days.

[huard]

Suggested change

	When converting to a leap year from a non-leap year, the 29th of february is simply removed from the array.
	When converting to a leap year from a non-leap year, the 29th of February is simply removed from the array.

[aulemahal]

En fait, the '360_day' behaviour I coded might not be the best.
Question for @tlogan2000:
What would be the expected behaviour when converting a 360_day calendar to a standard one:

1. Have the position of the data within a year stay approximately the same by a linear interpolation (the 5 or 6 missing point are now kinda "random" and different for leap and non-leap years).
2. Have the dates stay the same, meaning all 31st will be NaN + 29th and 30th of Feb. So losing 1 or 2 datapoints (now missing 7 instead of 5 or 6).
3. Have the dayofyear stay the same, having now the last week of the year missing.
4. Have the user give a list of 6 missing days.

[tlogan2000]

En fait, the '360_day' behaviour I coded might not be the best.
Question for @tlogan2000:
What would be the expected behaviour when converting a 360_day calendar to a standard one:

1. Have the position of the data within a year stay approximately the same by a linear interpolation
2. Have the dates stay the same, meaning all 31st will be NaN + 29th and 30th of Feb. So losing 1 or 2 datapoints (now missing 7 instead of 5 or 6).
3. Have the dayofyear stay the same, having now the last week of the year missing.

Definitely not option 3 I would think. Option 2 not great ... so I think I prefer option 1

Question though could nn interp be a better choice depending on variable?

Anyways I would go with linear for now and we can see if we add a nn interp as a user option at a later date

[tlogan2000]

En fait, the '360_day' behaviour I coded might not be the best.
Question for @tlogan2000:
What would be the expected behaviour when converting a 360_day calendar to a standard one:

1. Have the position of the data within a year stay approximately the same by a linear interpolation (the 5 or 6 missing point are now kinda "random" and different for leap and non-leap years).
2. Have the dates stay the same, meaning all 31st will be NaN + 29th and 30th of Feb. So losing 1 or 2 datapoints (now missing 7 instead of 5 or 6).
3. Have the dayofyear stay the same, having now the last week of the year missing.
4. Have the user give a list of 6 missing days.

Sorry I missed option 4. This seems ok I guess but should not be the default... Is this all coded already? Sorry haven't had time to look at the PR yet. Anyways, people already have trouble understanding the 360_day calendar so asking them to provide missing is likely to be an 'expert' only option

[aulemahal]

No, only 1 is coded. But to be clear : I am talking of interpolating the time coordinate only not the data. Right now, interp_calendar does that, reinterpolating datapoints on a new time coordinate aligning the data on its position within the year.
But convert_calendar doesn't touch the data (except for invalid dates that are dropped). Opt 1 is the one that realigns the data by interpolating the dayofyear attribute. Thus, the 5 or 6 missing datapoints. But that only makes sense daily (and subdaily) data.
On monthly data, that would mean that data points are not on the 1st of the month anymore... Opt 2 would not have that problem.

[huard]

Could only give a brief look, but nothing to comment on.