[CF-metadata] CF calendars (was: problem with times in PSD dataset)

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 19 Dec 2012 09:38:56 +0000

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 <j.m.gregory at reading.ac.uk>
> To: cf-metadata at cgd.ucar.edu
> 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
Received on Wed Dec 19 2012 - 02:38:56 GMT