Hi Cathy:

I think that you are using "backwards compatible" in a different way.

The current proposal(s) would not change files that are written with :Conventions="CF-1.x", where x <= 6. Files with x > 6 could still use the (ill-advised) old way if they want to, by putting an explicit calendar attribute in. But if theres no explicit calendar attribute, then these new files will be interpreted in a way that is less likely to give incorrect dates.

So, im not sure why you keep saying "shouldn't break current files", since there is no such proposal on the table.

John

On 12/17/2012 4:13 PM, Cathy Smith (NOAA Affiliate) wrote:
Cecelia

I think a solution shouldn't break current files which followed what had
been a standard for a long time (however ill-advised the standard was).
I don't have a good sense of what might break if the standard changed in
terms of software so I can' speak for all users but I do know many
people have downloaded our mean files with 1-1-1 base dates (ignoring
the climatologies for now). While we can potentially change what we have
either by changing the dates and/or adding a calendar attribute,
changing the default calendar may create errors in reading dates for
users who already have those files (which are currently CF complaint ).
And,  they won't have the same ability to change the files and they
wouldn't necessarily know they needed to.  I think no default at all
would be problematic as what would software do?  So, I would support the
inclusion of a calendar attribute that would be used by software if
there but using the old default calendar if not. Also, I would support
making a calendar attribute for new files mandatory (with an updated CF
version) but I would keep backwards compatibility unless it were
reliably shown it was not an issue with users.
I'm not convinced that the users needs (as opposed to developers) have
been adequately researched.

Cathy



On 12/17/12 12:56 PM, Cecelia DeLuca - NOAA Affiliate wrote:
Cathy,

Of the other options, do you find some (or all) completely unacceptable?
Are some better than others?

- Cecelia

On 12/17/2012 10:59 AM, Cathy Smith (NOAA Affiliate) wrote:
Cecelia
I support 1) mostly for backward compatibility. I would also strongly
encourage but not demand that users change their base dates to after
1800
when it makes sense to do so.

And, I (again) want to make sure that LTMs and their time values are
addressed before any decisions are made as to negative times and
using base dates of 1-1-1 and the issue of what year to use for
climatologies. LTM dates are a problem when one needs to use a
calendar based on real dates.

Cathy


On 12/12/12 9:04 AM, Cecelia DeLuca - NOAA Affiliate wrote:
Hi Steve, Jonathan and all,

There are not that many options being discussed.

With respect to the default calendar:

1 keep the Julian-Gregorian calendar as default (no change)
2 remove the Julian-Gregorian calendar as default, and have no
default calendar (grid analogy)
3 replace the Julian-Gregorian calendar as default with the
proleptic Gregorian calendar
4 replace the Julian-Gregorian calendar as default with a strict
Gregorian calendar

Maybe it makes sense for people to cite (or rank)  their preference
at this point?

There were a couple other proposals, depending on which of above is
selected:
5 create a strict Gregorian calendar (optional for 1, 2, 3 and
needed for 4)
6 remove the Julian-Gregorian calendar (impossible for 1, optional
for 2, 3, 4)

Again, maybe worth it to see where people are after the round of
discussion?

Best,
Cecelia



On 12/10/2012 12:40 PM, Steve Hankin wrote:
Hi Jonathan,

I'm not sure if my remarks below conflict with your proposed
resolution.  But they do dispute the facts you assert, and these
waters are so muddy that agreeing on the facts seems an important
first step.

On 12/10/2012 1:21 AM, Jonathan Gregory wrote:
Dear Jon

Just to repeat a remark that Steve Hankin made whose implications have not been 
explored in this discussion: different countries adopted the Gregorian calendar 
at different times.  (Greece didn't adopt it till 1923!)  So what is considered 
a valid Gregorian date varies from country to country (and some of those 
countries don't even exist any more, or at least the boundaries have changed...)
2. The non-proleptic Gregorian calendar is extremely problematic for historical 
observations as well as for models (astronomers use the Julian calendar 
consistently for this reason).
Yes, that's right. Nonetheless I don't think we can abolish the real-world
calendar, despite its ambiguities, because*_it's the one we really use!_*

Are you sure this is true?  Evidence seems to suggest that our
community has _no use for the mixed Gregorian/Julian calendar at
all_, except the need to resolve the backwards compatibility mess
we have created for ourselves.

  * In everyday life we use is the modern Gregorian calendar, and
    are not concerned with historical calendar changes.
  * In numerical climate modeling we use the proleptic Greogorian
    calendar.  (I'll wager you there is no serious paleo-modeling
    done with an 11 day discontinuity in its time axis. )
  * What do Renaissance historians use when discussing dates that
    are rendered ambiguous by differing timings of the
    Julian/Gregorian transition in different locations?  Do any of
    us know? Does it effect any use of CF that we are aware of?

As you say, we should be clearer about what the real-world calendar means, in
cases where_users really want to use it._

Who are these users?  Where is the user who intersects with our
community and really wants to use the mixed Julian/Gregorian
calendar?  The only potential user I can think of would be a
Renaissance historian looking at paleo climate model output.  That
hypothetical person would already understand that manual calendar
translations were needed to make sense of precise dates at that
time of history (and would almost surely shrug off an 11 day timing
uncertainty in a paleo climate model outputs in any case).

As Cecelia said, lets drive a stake through the heart of this
madness ... at least to the maximum degree we can given inescapable
backwards compatibility concerns.

    - Steve


_______________________________________________
CF-metadata mailing list
CF-metadata@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.del...@noaa.gov
Phone: 303-497-3604


_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
----------------------------------------------
NOAA/ESRL PSD and CIRES CDC
303-497-6263
http://www.esrl.noaa.gov/psd/people/cathy.smith/

Emails about data/webpages may get quicker responses from emailing
esrl.psd.d...@noaa.gov


_______________________________________________
CF-metadata mailing list
CF-metadata@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.del...@noaa.gov
Phone: 303-497-3604

--
----------------------------------------------
NOAA/ESRL PSD and CIRES CDC
303-497-6263
http://www.esrl.noaa.gov/psd/people/cathy.smith/

Emails about data/webpages may get quicker responses from emailing
esrl.psd.d...@noaa.gov



_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to