⇐ ⇒

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

From: Cecelia DeLuca - NOAA Affiliate <cecelia.deluca>
Date: Tue, 18 Dec 2012 10:53:35 -0700

Hi Jonathan and all,
>> 2 remove the Julian-Gregorian calendar as default, and have no
>> default calendar (grid analogy)
>> 4 replace the Julian-Gregorian calendar as default with a strict
>> Gregorian calendar
> I think either of these would work. 2 causes more aggravation. It means that
> data which doesn't state the calendar attribute is illegal and will produce
> errors, even if it's entirely unproblematic such as "days since 2012-1-1". It
> would make CF more intolerant of existing practices than it usually has been.
> At the moment, CF accepts COARDS time coordinates; with this change, COARDS
> data would not be acceptable.
>
> Hence I would still prefer 4. The aim of this would be to make the default
> illegal in cases where there is a serious chance of unsafe time units, and the
> obvious criterion seemed to prevent dates before the invention of the Gregorian
> calendar. In particular that will exclude reference years of 0 and 1, which
> are often problematic. However, I don't feel strongly about it.
If a deprecation process were in place, would that affect your ranking
of these options?

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).

The other reasons do still stand - the strict Gregorian calendar is
unsuitable for many
climate model experiments that must move smoothly to dates before the
1500's, and the
Gregorian calendar is frequently not used as the default in models in
any case (in favor
of something easier, like no leap). It does still seem cleaner to have
tools request a
calendar attribute or generate an obvious error rather than generating
errors only on
some dates, which could be harder to catch. (However, I do see the
benefit of a strict
Gregorian calendar default still working for current dates for
observational data, and
could imagine this outweighs other concerns.)

Anyway, I thought the notion of deprecation, and an adjustment period,
might make it
easier to make a "bigger" change and remove the default - what do you think?

Cecelia

-- 
===================================================================
Cecelia DeLuca
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder 80305-337
Email: cecelia.deluca at noaa.gov
Phone: 303-497-3604
Received on Tue Dec 18 2012 - 10:53:35 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒