I also think we should recommend that the calendar attribute should always be defined (if we continue to allow a default). Recommending this would mean, for instance, that the cf-checker would give a warning if the calendar is not defined, but it would not be an error. Jonathan
On Wed, Dec 19, 2012 at 09:23:34AM +0000, Jonathan Gregory wrote: > Date: Wed, 19 Dec 2012 09:23:34 +0000 > From: Jonathan Gregory <[email protected]> > To: [email protected] > Subject: [CF-metadata] CF calendars (was: problem with times in PSD dataset) > User-Agent: Mutt/1.5.21 (2010-09-15) > > Dear Cecelia et al. > > > An "entirely unproblematic" calendar attribute such as days since > > 2012-1-1 could be > > quite problematic if it is March 1, if it is unclear if you are on a > > Gregorian, no leap, > > or 360 day calendar, all in active use in modeling and all yielding > > potentially different > > answers. A no default strategy might lessen the chances for > > mismatches (or at > > least, steer people from the implicit assumption that dates are > > likely to be Gregorian). > > Clearly I should be more precise in what I say! > > When I said "entirely unproblematic" in this case I meant that the mixed > Julian-Gregorian calendar was not a problem for it. If it is known to be in > the real world, it is well-defined, because it is later than the change from > Julian to Gregorian in all countries. I agree of course that Gregorian, 360-, > 365- and 366-day calendars would all give different answers still. Hence that > choice does have to be clear. > > I do think that it would be right to deprecate the use of the mixed Julian- > Gregorian calendar for all cases except where there is really a need for time > coordinates before the change of calendar. There may be no such cases (as I > agree in my previous posting, to Steve) but we cannot be sure and I would > guess it might occasionally be needed. > > I don't think deprecation (which should be done anyway) changes my own view > about the default. I think the default should be the real world *but* I think > it would be fine to redefine the default to exclude the mixed calendar (i.e. > make it strict Gregorian). Allowing strict Gregorian to go back to 1582 is the > most generous choice. We could choose a later date. However, since Greece and > Russia (and maybe elsewhere) changed in the 20th century, we cannot choose a > date that is both late enough to avoid the transition in all countries and > early enough to include the period of instrumental data, which goes back to > the 19th century and earlier, for which there is a very likely need in CF. > Thus 1582 seems a simple and logical choice, and still helps as it would make > reference dates of year 0 and 1 fail. I suspect they are the commonest > choices that are made when the reference date has not been specifically chosen > to suit the data. > > I've probably said all this before, but to summarise, my first choice would > be to change the default to be strict Gregorian from 1582, which excludes the > worst problem, but if others argue that there is need to prevent confusion > between real-world and model calendars for reference dates more recent than > 1582, I would accept my second choice, which is not to allow a default at all. > That's my second choice because I think it would cause annoyance for many > people who've been used to coding COARDS-like real-world time coordinates > without defining their calendar, whose datasets might become illegal, either > because their software is upgraded to use the new version of CF in which this > change is made, or because their software changes its default behaviour > without > paying attention to the Conventions attribute, as Chris also mentions. > > Best wishes > > Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
