Dear @martinjuckes and @Dave-Allured > For 365_day I agree that the current definition is confusing -- how about > "All years are 365 days with months as in a non-leap year of the Gregorian > calendar", and a similar statement for 366_day.
Yes. I agree. > I agree with Dave's recommendation to avoid the new ISO 8601-2 explicit form > for dates (YB etc). I do too. > I think we should spell out what we are prepared to accept. Yes. Since CF generally supports udunits formats for units, we ought at least to allow what udunits does for time, but I haven't found out in the units documentation what formats it accepts. I think it will allow Y[-M[-D [h[:m[:s]]]]], where Y can be a large positive or negative number or zero. (NB udunits itself only handles the real-world calendar, but we use its format for the others.) I agree with @Dave-Allured that it's OK to continue to allow but deprecate the special use of year 0 in the real-world calendar. > if we can get consensus that dates earlier than year 1 are not valid in the > existing `standard` (or default) and `julian` calendars under CF ... I think that years<1 should be deprecated in these calendars, but not disallowed, because of backward compatibility. What do @martinjuckes and others think? Above (https://github.com/cf-convention/cf-conventions/issues/298#issuecomment-698987558) I have made proposals for new calendars, going before year 1, and asked whether `gregorian` should be redefined. Jonathan -- 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-704236236 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].
