> 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
Hmm -- this seems to contradict Steve's "no known users".
BUt anyway, I wonder if folks currently using such files are actually
getting the "correct" results, when they do.
For instance, in my naivet?, I never thought about calendars when
using netcdf files -- I simple converted "something since some date"
to Python datetime objects using python's datetime package, which uses
"An idealized naive date, assuming the current Gregorian calendar
always was, and always will be, in effect"
So I would have gotten the "wrong" results.
I've lost track whether UDunits does the mixed calendar right, but I'm
sure not all libraries one might use do.
So is this a use case se need to preserve?
-Chris
(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 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
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at 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.data at noaa.gov
>
>
>
> _______________________________________________
> 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
>
>
> --
> ----------------------------------------------
> 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.data at noaa.gov
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
Received on Mon Dec 17 2012 - 16:50:14 GMT
