This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#96: Julian/Gregorian calendar name and constraints -----------------------------+---------------------------------------------- Reporter: Dave.Allured | Owner: [email protected] Type: enhancement | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: calendar time julian gregorian udunits -----------------------------+---------------------------------------------- Comment (by jonathan): Dear Dave You did indeed explain your rationale before. I agree with your concerns over the default calendar and I am sympathetic to the motivation. My concern is whether introducing a new calendar will actually bring about an improvement in practice if there is no incentive to adopt it. Unless we are convinced that it will help this would be an unnecessary complication in the convention. One extra step we could take would be to recommend against relying on the default. The consequence would be that the CF checker would give a warning whenever the calendar attribute was not present for a time coordinate (from the next CF release, so it would not warn about datasets written with CF 1.6 or earlier). This warning might encourage the authors of new datasets to include the attribute. A further step, more serious, would be to deprecate the existing default calendar, even if explicitly called `standard` or `gregorian`. Again, deprecation (i.e. recommendation not to use it) would produce a warning. The warning could at the same time suggest using the new calendar instead for the real world. What do you and others think of that? Would it be beneficial? Would it be too annoying? If we agree to do this, it would be done by inserting text in the definition of this existing calendar. Since udunits refers to the current default as "mixed Gregorian/Julian", it would be consistent to call your new calendar `mixed_gregorian_julian`. That would also involve less change to the convention than switching all the occurrences in the text to "Julian/Gregorian". I would further suggest that the name should say more explicitly what the calendar is, to distinguish it from `gregorian`. To do that, perhaps the new calendar could instead be called `strict_gregorian_julian`. One aspect of the strictness is to exclude negative years and year zero. Another that you suggest is that transitional dates be excluded, but since CF is defined using udunits for real-world time coordinates, transitional dates are in any case impossible to encode, so they do not need to be excluded. However, we should explicitly exclude 'reference dates' (i.e. 'since' in the units) which are transitional dates. How about this: `strict_gregorian_julian`: Mixed Gregorian/Julian calendar, with constraints. The reference date (following `since` in the time units) is not allowed to be any of the dates in the transitional period 1582 October 5 through 1582 October 14 inclusive. Neither the reference date nor any date which is encoded with this calendar is allowed to be in year zero or a negative year. Finally, you have suggested some useful text describing when the calendar should be used. There is also some existing text about this, however, at the end of 4.4.1. Combining your text and the existing text, I'd propose: Because of problems caused by the discontinuity, it is recommended that the `strict_gregorian_julian` calendar be used only in datasets with real- world historical dates which span the change of calendar from Julian to Gregorian. In datasets with real-world historical dates that all precede the change of calendar, the `julian` calendar should be used. In datasets with real-world historical dates that all follow the change of calendar, and in simulated datasets in which there is no change of calendar, the `proleptic_gregorian` calendar should be used. How would that be? Cheers Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/96#comment:7> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
