Jonathan and all
There are aspects of this decision that relate to data sets, models,
model/data
set alignment, tools, and the scope of the CF user base.
I agree that changing the default is problematic. Tools (and people) would
have a hard time with prior to change/post change datasets that used the
default,
in which the only calendar indication was the version of CF used.
However, the current default is also problematic - reasons I see are:
1) it does send a message to modelers who find the default unusable,
2) because different calendar defaults are used on the modeling and
data side, current tools are limited to particular calendars, affecting
users,
and 3) the mixed Julian-Gregorian calendar is an ugly beast to peg as the
standard forevermore.
It's probably possible to overcome 2) by updating tools to include
additional
calendars. The calendar definitions in CF are pretty clear and it does
not seem necessary to change existing ones, but maybe it is a good idea
to add another, strict Gregorian (error before 1582).
If the calendar default was removed in a future version of CF, this would
create some issues, but it would also have benefits that may outweigh them:
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?
Some tools might be modified to expect all data sets to specify calendars.
These would produce errors if no calendar was specified, or in some cases,
as Jonathan suggested, the user could be asked to provide the calendar
if none was found.
However, I imagine most tools would continue to assume the current default.
The way to talk about these tools could be that they would work on
CF-compliant
data sets that spanned versions of CF pre/post removal of the default
calendar
I would expect that most software based on CF would not have to change.
This does not seem so bad to me. The removal of the default solution should
not produce the nastier kinds of errors that you would get if you
changed the
default.
People will weigh costs and benefits differently - and I may be missing some
major consideration above - but for me, it seems like it's worth
it to remove the weird default calendar and move on.
Best,
- Cecelia
On 12/7/2012 6:53 AM, Jonathan Gregory wrote:
> Dear all
>
> I think that we should be very cautious about backwards-incompatibility, even
> when changing CF versions. I would be worried about making a change which
> means metadata would have a different meaning according to which version of
> the convention is used. I know in principle it is safe because the file states
> the version, but I don't think we can depend on the version to be coded
> correctly, or on software to make correct use of it. Although these are errors,
> we ought nonetheless to design the convention to be as robust as possible in
> an error-prone world.
>
> Therefore I don't think it is safe to change the the default calendar from
> gregorian to proleptic_gregorian, because that could change the date you
> get for a given time coordinate. However, I do think it would be safe to make
> it illegal to use the default calendar for reference dates earlier than
> 1582-10-15, or for negative time coordinates (to make sure that dates before
> 1582-10-15 cannot be specified). In that case, real-world data for which there
> is no problem would be unaffected, but software would reject time coordinates
> whose interpretation is problematic. Software could provide an option whereby
> the user could state what the calendar actually is, when not specified, in
> order to override the error if the user knows what it truly is. Alternatively,
> they could easily repair the file with ncatted or some such tool.
>
> It should still be possible to use the real-world calendar before 1582-10-15,
> because CF might be used for real-world historical data earlier than that date,
> but it would be necessary to state the calendar explicitly.
>
> 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 Fri Dec 07 2012 - 12:59:10 GMT
