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

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

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:23:34 GMT