Should non-real-world calendars allow dates with year zero?

[spencerkclark]

Currently while reference dates with year zero are allowed for all non-real-world calendars (see Unidata/netcdf4-python#470):

In [1]: import cftime

In [2]: cftime.num2date(range(370, 375), 'days since 0000-01-01', 'noleap')
Out[2]:
array([cftime.DatetimeNoLeap(1, 1, 6, 0, 0, 0, 0, 1, 6),
       cftime.DatetimeNoLeap(1, 1, 7, 0, 0, 0, 0, 2, 7),
       cftime.DatetimeNoLeap(1, 1, 8, 0, 0, 0, 0, 3, 8),
       cftime.DatetimeNoLeap(1, 1, 9, 0, 0, 0, 0, 4, 9),
       cftime.DatetimeNoLeap(1, 1, 10, 0, 0, 0, 0, 5, 10)], dtype=object)

Some cftime date types (all but Datetime360Day) with year zero are not. For example:

In [3]: cftime.num2date(range(5), 'days since 0000-01-01', 'noleap')
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-3-f544a558adb7> in <module>
----> 1 cftime.num2date(range(5), 'days since 0000-01-01', 'noleap')

cftime/_cftime.pyx in cftime._cftime.num2date()

cftime/_cftime.pyx in cftime._cftime.utime.num2date()

cftime/_cftime.pyx in cftime._cftime._DateFromNoLeapDay()

cftime/_cftime.pyx in cftime._cftime.DatetimeNoLeap.__init__()

cftime/_cftime.pyx in cftime._cftime.assert_valid_date()

ValueError: invalid year provided in cftime.DatetimeNoLeap(0, 1, 1, 0, 0, 0, 0, 2, 1)

This behavior seems inconsistent (and I think may have been introduced in #12, where I followed the logic that had been established in assessing the validity of dates under timedelta arithmetic). Should this be relaxed?

[davidhassell]

According to the CF conventions (http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#climatological-statistics), I think that the current behaviour is actually the right thing to do:

The COARDS standard offers limited support for climatological time. For compatibility with COARDS, time coordinates should also be recognised as climatological if they have a units attribute of time-units relative to midnight on 1 January in year 0 i.e. since 0-1-1 in udunits syntax, and provided they refer to the real-world calendar. We do not recommend this convention because (a) it does not provide any information about the intervals used to compute the climatology, and (b) there is no standard for how dates since year 1 will be encoded with units having a reference time in year 0, since this year does not exist; consequently there may be inconsistencies among software packages in the interpretation of the time coordinates. Year 0 may be a valid year in non-real-world calendars, and therefore cannot be used to signal climatological time in such cases.

[spencerkclark]

Thanks @davidhassell -- I agree that year zero should not be allowed for real-world calendars based on this standard. I guess I wonder if it should be for non-real-world calendars (e.g. noleap), based on this portion of the statement above:

Year 0 may be a valid year in non-real-world calendars, and therefore cannot be used to signal climatological time in such cases.

and the fact that cftime already allows units attributes with a year zero reference date in such cases, Unidata/netcdf4-python#470.

I don't have a strong opinion here though, so I'm totally fine leaving this be for now. I recognize these standards are complicated topics.

[jswhit]

year zero is allowed in all non-real world calendars now, but not for real-world calendars. There appears to be consensus that this is the best solution for now, so closing...