Dear @Dave-Allured , @JonathanGregory , I agree with Jonathan's point that someone may want to encode real world data from the 16th century (e.g. [weather records from 16th century diaries](https://link.springer.com/article/10.1023/A:1005505113244)) .. and so we should maintain the existing support for using actual the mixed Julian/Gregorian calendar.
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`. I agree with Dave's recommendation to avoid the new ISO 8601-2 explicit form for dates (`YB` etc). I think we should spell out what we are prepared to accept. E.g. Would we accept the basic form which has no separators within date and time (e.g. `19850412T101530`)? If the basic form is allowed, it is necessary, to avoid confusion, that a fixed number of digits be used for the years (4 by default, but it can be expanded as long as the length is agreed between parties exchanging data). If we stick to what they call the extended form (e.g. `1985-04-12T10:15:30`) the number of digits in the year can be varied without ambiguity. There is currently a special meaning attached to reference dates of the form `0-1-1`, for backward compatibility with COARDS, in section 7.4. Can we remove this feature from `CF-1.9`? -- 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-699693620 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].
