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
