I need to further address backward incompatibility for the current proposal to **include year zero** in the unadorned label **proleptic_gregorian**. It has already been said that there are conflicting interpretations between several software packages. @jswhit [mentioned this above](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/298*issuecomment-792418770__;Iw!!G2kpM7uM-TzIFchu!hP7GsdBB1e8DNYrXpbHjm4DD04kdtymtyJDTrHoHQOgnPuO2I9hPtAidupqTsjoxKcTQgagaLMk$ ) regarding the cftime python module. There is further concern in [cftime issue #233](https://urldefense.us/v3/__https://github.com/Unidata/cftime/issues/233__;!!G2kpM7uM-TzIFchu!hP7GsdBB1e8DNYrXpbHjm4DD04kdtymtyJDTrHoHQOgnPuO2I9hPtAidupqTsjoxKcTQJA63lgg$ ). Cftime is not the only library that uses no-year-zero encoding.
My opinion is that this particular problem is limited and manageable, we should proceed to define **proleptic_gregorian** to include year zero for CF purposes, and this will result in a simpler future. Here are some supporting arguments. * The status quo with dual interpretations is not tolerable going forward. CF needs to choose to include or exclude year zero, or else to prohibit year zero and negative years altogether from the unadorned label **proleptic_gregorian**. * CF is limited to the contents of **netCDF files** only. Behavior of external software is out of our control. We can only hope that external software will not label certain behavior as **CF** before standard behavior is actually adopted by CF. * Problematic cases are rare, or so I speculate. The use of **proleptic_gregorian** excluding year zero is limited to only cases that used **negative** year numbers in time values, or in the units string. Furthermore, such cases must have used one of the software libraries using the **no-year-zero interpretation**. Most CF applications deal only with observations, forecasts, and modeling in modern times. Therefore my guess is that use of negative years, and therefore backward incompatible cases, are rare. If anyone knows of such incompatible cases, it would be worth mentioning here. * There have been sentinels. I would expect that persons using incompatible negative years in **proleptic_gregorian** would at some point have run their files through programs such as ncdump and Panoply, and noticed the one-year discrepancy. This should serve to have reduced the extent of cases using this encoding. * The embedded CF version number less than 1.9, in combination with the **proleptic_gregorian** attribute value, can help to identify suspicious cases. * Incompatible cases can be remedied. When an incompatible data set is discovered, either the time coordinates can be rebased to include year zero, or else we can consider adding a new calendar label like **proleptic_gregorian_nozero**, similar to earlier suggestions by @JonathanGregory. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/298*issuecomment-809737706__;Iw!!G2kpM7uM-TzIFchu!hP7GsdBB1e8DNYrXpbHjm4DD04kdtymtyJDTrHoHQOgnPuO2I9hPtAidupqTsjoxKcTQgUaKVJI$ 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].
