Interpretation of negative years in units

[peterkuma]

Hi,

I have encountered an issue with handling of negative yeas in the units attribute of time variables. I am not sure if it is something which can be fixed, but maybe it can be at least clarified in the documentation. The units attribute specifies a reference date in an YYYY-mm-dd format, similar to ISO 8601. Currently, negative values of year are handled in cftime and udunits by assuming that year 0 does not exist, i.e. year 0001 is preceded by year -0001. This behaviour is different from a perhaps more standard assumption that year 0001 is preceded by year 0000, as in ISO 8601. Depending on the assumption, negative reference years result in a difference of one year when interpreting the time variable. At least some software such as Panoply assumes year 0 exists when interpreting the reference date.

This problem comes up when using Julian date in time variables, which has a reference date of -4712-01-01T12:00 UTC (assuming year 0 exists) or -4713-01-01T12:00 UTC (assuming year 0 does not exist), i.e. 1 January 4713 BCE, 12:00 UTC. Because of this issue, using Julian date in NetCDF files produces software-dependent results - in order to show correct dates, netCDF4 in Python would require units days since days since -4713-01-01 UTC, while Panoply would require units days since -4712-01-01 UTC.

This issue is somewhat related to #193 and #71.

Regards,

Peter

[jswhit]

This comes comes up every once in a while, and probably should be added to the docs. The year zero does not exist in the Gregorian or Julian calendars that the CF conventions reference, but it does exist in astronomical systems. In fact, the use of the year zero in the reference time in CF has a special meaning (it implies the use of 'climatological time' - which cftime does not support).

It would be possible to support astronomical year numbering with a kwarg.

[peterkuma]

I think a kwarg would be useful, but also it won't solve the whole issue by itself because there is nothing in the NetCDF file which indicates which numbering to use. Therefore, if someone receives such a file, they won't know how to interpret time variables without external information about the numbering. One would have to supply this information either in a new attribute (like calendar_numbering = "astronomical" or somehow inside the units or calendar attributes. I can cross-post this to cf-convention/cf-conventions to see what they think.

[jswhit]

Seems like this discussion is converging on the idea of having _withzero variants of the real world calendars, and allowing year zero in the non-real-world calendars (360_day,365_day and 366_day).

From the point of view of implementation in cftime, the easiest thing would be to add a withzero kwarg that is False by default (preserving the current behavior).

[jswhit2]

PR #202 includes hooks to allow for year zero in real-world calendars once the CF conventions are updated.

[jswhit]

Closing this for now, will revisit when and if cf conventions are updated

[jswhit]

PR #234 adds a has_year_zero kwarg to allow for astronomical year numbering for 'real-world' calendars.