Hi Jonathan,
On 12/9/2012 8:45 AM, Jonathan Gregory wrote:
> Dear Cecilia
>
> Thanks for your posting. Are we in agreement? I think that we are.
I think we are close. The difference I see is that you are recommending
a change to a
strict Gregorian calendar as the default, and in my last mail I had
advocated no default.
>> it is a good idea to add another, strict Gregorian (error before 1582).
> Thanks for seeing it like that. Yes, perhaps we should define what I suggested
> as a new calendar: strict_gregorian, which is not allowed to have a ref date
> before 1582, or to use negative time coordinates, or to describe dates before
> 1582 (which would be impossible given the first two conditions). (Note, I am
> not personally the eponymous strict Gregory.)
A relative advantage of no default is that it's not necessary to either
change the definition of the current CF mixed Gregorian calendar or create a
new CF strict Gregorian calendar. It sounds like there are issues with
making
the strict Gregorian calendar the default on the data side, and it
does not work any better than the mixed Gregorian on the modeling side.
I can still imagine reasons to want to define a strict Gregorian
calendar in CF,
but with more time, and thought, and perhaps in a less than central role.
Maybe the main thing no default could provide is a path to move forward - a
chance to develop additional calendars and conventions that work better for
particular purposes, and put them into use without needing to worry about
creating or conflicting with the default as an implicit recommendation.
It's more of
a view of the calendar as analogous to a grid type, where the notion of a
default is generally not well defined.
Do you see a reason why a default is needed?
In that case, we could change the default in the next release from gregorian
or standard to strict_gregorian. For software which is careful about versions,
this would mean that dates in the default calendar before 1582 would give an
error. This would be a safe failure, rather than a wrong answer.
With respect to tools, it may be that the no default solution is a safer
change...
If the CF version is not taken into account, and the calendar not specified:
- with no default, tools would either work as previous, or would fail on
all data points.
- with the strict Gregorian default, tools would either work as
previous, or would
fail on some data points.
Failure for some data points seems more prone to create confusion about the
behavior of tools before and after the change, and more likely to create
user
errors when, for example, it is not noticed that some subset of data
points has
an invalid date.
This may be worrying too much - maybe it is reasonable to expect tools
to always
check the CF version? That just doesn't seem to be the way that life
(or software)
turns out.
>> Some data sets would be CF compliant only under particular versions of CF.
>> Is this the first time that a change to CF would have such an impact?
> In the sense of old data becoming invalid in a *later* version, yes I think
> it is. Of course new features always allow datasets which are invalid in an
> *earlier* version.
That's impressive... and does beg the question of whether a change in
default calendar would be worth it.
Best,
Cecelia
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
===================================================================
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 Mon Dec 10 2012 - 11:13:01 GMT
