On 2015-05-10 Jonathan Gregory <j.m.gregory at reading.ac.uk> wrote:
> I think it might well be OK to retain the existing calendar name of "gregorian" from CF1.7,
I read this to mean that for new datasets this name would mean the same as the previously proposed "gregorian_noleaps".
> but give it a more precise definition, in order to eliminate the ambiguity about leap seconds. (Of course, there is nothing we can do to remedy this with existing data.)
This means that for the reader the CF version must be consulted in order to determine if leap seconds can be unambiguously assumed to be absent (i.e. still ambiguous if CF<=1.7). That might work, with a little risk that sloppy/eager writer implementers may still just up their CF version number unaware of the subtle change in the definition of the "gregorian" property, for which cases the interpretation would still remain ambiguous, except of course that now we can always blame it on a faulty writer. ;-)
In case the name "gregorian_noleaps" is still to be considered, please note that there is a little ambiguity in that as well. I first thought the "leaps" part was referring to leap years, for instance, not the leap seconds. (Yes, there are still sloppy implementations of leap years around in various software, deliberate or not...) I propose "gregorian_noleapseconds" instead.
> * We state that all the other calendars have fixed-length days with no leap seconds.
Isn't this a potential per-calendar issue? Why not just state it specifically with the definition of each calendar that gets supported, since a new name must be assigned to it (and described) anyway?
> A decomposition of metadata is cumbersome if it isn't generally relevant. Suppose X can take values X1 or X2; if it's X1 then Y can be Y1 or Y2, whereas Y is irrelevant if it's X2. In that situation I would have a single attribute with possible values X1_Y1 X1_Y2 and X2. A single
> attribute is easier for scanning a dataset, less work to write and read, and more likely to be correct because it's less likely that Y will not be coded if relevant or will be coded if irrelevant.
Good reasoning, and as one that often is exposed to the task of reading such data, I will support this decision!
> [...] we require the calendar always to be specified (no default). This would be quite a radical step, but forcing the noleaps/utc property to be explicitly stated is only way
> I can see to avoid in future the ambiguity about whether elapsed times have been encoded with or without leap seconds.
I agree, especially since if the property is missing there will be an incentive for the reader to either resolve the ambiguity completely (eg, checking with its producer), or they are aware they're taking a guess on it.
> * We introduce a new calendar "mixed_gregorian_julian", which is the calendar of udunits, with no leap seconds. However we make it stricter than currently, in these ways: (1) The reference date is not allowed to be any of the dates in
> the transitional period 1582-10-5 to 1582-10-14 inclusive.
I guess the question soon becomes how to represent such historic dates from countries that have a later transition period/time. Any date before 1582-10-14 can probably just be considered a Julian date from either of these places, but later dates would be ambiguous.
--
-+-Ben-+-
Received on Sun May 10 2015 - 06:36:35 BST
