Thank you, @peterkuma, for the useful information, and to @martinjuckes for his 
correction to the question - not "Is there a year zero in the calendar?" but 
rather "How do we encode a given calendar year in the time stamp?". I think 
these are linked in the CF convention. To be precise, I think we could say that 
the CF `calendar` attribute indicates _both_ the set of valid dates in the 
calendar (YYYY-MM-DD) _and_ the specification for mapping a valid date-time to 
a unique number (i.e. the encoding of date-time as a time coordinate). Though I 
appreciate Martin's point that these are two concepts, which is why he prefers 
a qualifier, since you must have both and there are few possible combinations 
it feels more robust to me to keep an indivisible attribute for them.

Therefore I suggest that for the default/`gregorian`/`standard` calendar, we 
recommend that the reference date should not be earlier than year 1, and that 
no date earlier than year 1 should be encoded in this calendar, to avoid the 
ambiguity. That means the CF-checker would produce a warning (but it's not an 
error). We shouldn't retrospectively define what negative years mean because we 
don't know the intention of existing data. I suggest that we define two new 
calendars:

  * `gregorian_zero`, in which year 0 means 1 BC, and any year is allowed in 
the reference date.

  * `gregorian_nozero`, in year -1 means 1 BC, year 0 is not allowed in the 
reference date and dates in year 0 cannot be encoded. These latter two would 
give errors.

Any other calendar where the same ambiguity exists could have the same 
treatment, if there are use-cases which need them. This would be for Julian and 
proleptic Gregorian calendars, since the other two are model calendars in which 
I think we can assume year 0 is valid.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/298#issuecomment-698402127

This list forwards relevant notifications from Github.  It is distinct from 
[email protected], although if you do nothing, a subscription to the 
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to 
[email protected].

Reply via email to