Standard or Gregorian calendar

[larsbarring]

As of Climate & Forecasting Conventions version 1.9 (full text) released last September the gregorian calendar is deprecated:

standard
Mixed Gregorian/Julian calendar as defined by UDUNITS. This is the default. A deprecated alternative name for this calendar is gregorian. ...

I raised an cftime issue regarding this, which prompted a change of the "main" calendar class from DatetimeGregorian to the new DatetimeStandard class (and to keep the former for backward compatibility). However it seems that this change could not be fully implemented because of problems with xarray build tests. But maybe there has been some recent developments that would now allow cftime to reintroduce the full update?

Thanks /Lars

[spencerkclark]

Could you elaborate on what you mean by the "full update"? Do you mean completely removing the DatetimeGregorian class? At this moment -- through #6082 -- the development version of xarray should be compatible with the development version of cftime, but the test suite would still break if DatetimeGregorian were removed.

[larsbarring]

Yes -- see this comment in the closed PR #257. I.e. cftime would still be able to "understand" the gregorian calendar and its corresponding class DatetimeGregorian, but include the functionality to always output the new DatetimeStandard class thus better representing the gist of the CF change. This was originally intended in the PR, but removed because it broke xarray. What now remains implemented is the new class DatetimeStandard.

From a coding perspective this request could perhaps be seen as "just a name change", but from a user perspective this is more of a real change as the string representation changes from "gregorian" to "standard", which is exactly what the CF change is about.

ping @jswhit

[spencerkclark]

Thanks, I see. #6082 only fixed errors that were introduced by Unidata/cftime#257, so if the "full update" were made, the errors @jswhit referenced would still crop up. I think the eventual goal in cftime is to remove the calendar-specific subclasses of cftime.datetime completely, since cftime.datetime instances can now be calendar-aware. Fully shifting to this in cftime was also blocked by xarray at the time.

My preference in xarray would be to prioritize adding compatibility for calendar-aware cftime.datetime instances, which would enable cftime to remove the subclasses. I think this would make the DatetimeStandard vs. DatetimeGregorian distinction a moot point.