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
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
===================================================================
Cecelia DeLuca
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder 80305-337
Email: [email protected]
Phone: 303-497-3604
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
