On Wed, May 20, 2015 at 7:43 AM, John Graybeal <jbgraybeal at mindspring.com>
wrote:
> Without fully appreciating _all_ the particulars (sorry!), I think
> Jonathan's diagnostic (that people would tend to keep using gregorian) is
> correct.
agreed.
> I like the idea of a warning against that practice, with a recommendation
> to use gregorian_nls if that's appropriate (and of course a pointer to the
> relevant sections of the standard).
But I'm not sure that we need to lighten the spec. Let's say that
"gregorian" in no CF-1.7+ compliant. Yes, people will still use it, so they
will have slightly non-compliant files, but folks will still be able to use
them.
But people are more likely to do the right thing if is officially
non-=compliant than if it is simply against recommendations.
If the goal is to get as many files as possible to use gregorian_nls (when
appropriate) then it probably should be the standard.
Note that I'm still a bit confused about the particulars here:
It seems to me that the calendar describes what the epoch in a time
variable means.
the elapsed time _should_ be correct. period. If it says X seconds since
the epoch, then it should be X seconds since the epoch.
I understand that someone may have made a mistake/used an inappropriate
library, etc, such that there may be an off by-a-couple-seconds error in
the elapse time. But are we really trying to include something in the
standard to accommodate that?
There could be errors / lack of precision in ANY variable in a file --
what's so special about this one?
Or maybe I'm mis-interpreting the plan here.
-Chris
>
> john
>
>
> On May 20, 2015, at 07:16, Jonathan Gregory <j.m.gregory at reading.ac.uk>
> wrote:
>
> > Dear Jim
> >
> > If instead we decided not to redefine gregorian, but to replace it with
> > gregorian_nls, that would be a more definite indication that action had
> been
> > taken to use the right code, wouldn't it. Would you be content with that?
> >
> > This isn't my favourite option, as you know. While it doesn't seem
> onerous,
> > I'm not sure it's realistic. I suspect that people might continue to
> > code calendar="gregorian" anyway, even if the CF checker reported it as
> an
> > error, but perhaps I am too pessimistic! A compromise would be to
> *recommend*
> > coding gregorian_nls, meaning the same as (redefined) gregorian, but
> indicating
> > more definitely that there were no leap seconds in the encoding, in
> order to
> > reassure the user it had been done correctly. If we took that course,
> the CF
> > checker would give a warning if gregorian was coded, and recommend that
> it
> > should be changed to gregorian_nls. This is a bit like your idea of
> having an
> > extra attribute, but it's implied by the existing attribute. I would be
> > comfortable with this compromise. What do you and others think?
> >
> > Best wishes
> >
> > Jonathan
> >
> > ----- Forwarded message from Jim Biard <jbiard at cicsnc.org> -----
> >
> >> Date: Wed, 20 May 2015 09:15:01 -0400
> >> From: Jim Biard <jbiard at cicsnc.org>
> >> To: cf-metadata at cgd.ucar.edu
> >> Subject: Re: [CF-metadata] How to define time coordinate in GPS?
> >> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
> >> Gecko/20100101 Thunderbird/31.7.0
> >>
> >> Jonathan,
> >>
> >> Given the direction we have taken of using a new calendar name to
> >> capture the other aspect, we are limited in our options. We could
> >> specify an attribute that, if present, could be taken as a
> >> "guarantee" (although people admittedly could set the attribute and
> >> still do it wrong). The attribute name could be time_encoding with
> >> values of 'true_elapsed' and 'unknown'. The value of 'unknown' would
> >> be the default, so if the attribute was not specified, the
> >> assumption would be that you can't be sure. Most data producers
> >> would have no need to specify the attribute, since their time
> >> resolutions are not so fine as to make them sensitive to the
> >> potential problems.
> >>
> >> Other than your suggestion about 1.7 implying greater care taken,
> >> that's what comes to mind.
> >>
> >> Grace and peace,
> >>
> >> Jim
> >>
> >> On 5/19/15 5:23 PM, Jonathan Gregory wrote:
> >>> Dear Jim
> >>>
> >>>> We are definitely getting much closer to full agreement. I continue
> >>>> to think that a separate time_system (or some such) attribute would
> >>>> be a much better way to handle this than modifying the calendar
> >>>> attribute, and that space-separated calendar modifiers would be next
> >>>> best after that, but I will bow to the apparent majority and agree
> >>>> to your proposal for modified definitions of the general reference
> >>>> time and Gregorian calendar, the addition of a new gregorian_utc
> >>>> calendar, etc, as you just outlined.
> >>> That is good news. I am glad that we understand things in a compatible
> way now
> >>> thanks to this discussion, and I am grateful for your flexibility and
> willing-
> >>> ness to compromise on the implementation.
> >>>
> >>>> There are two remaining things that I would like to see.
> >>>>
> >>>> 1. A section that explains the importance for data producers and
> >>>> consumers of using the right time handling routines for the input
> >>>> time data and the calendar chosen if your time resolution makes you
> >>>> sensitive to errors on the order of 1-30 seconds, pointing out (for
> >>>> example) that using the standard *nix time functions with sets of
> >>>> correct UTC timestamps will produce incorrect elapsed time values
> >>>> under the right conditions. Such a section would also point out to
> >>>> data consumers that if errors on this level are significant to them,
> >>>> they shouldn't assume that existing observational datasets are free
> >>>> of these errors.
> >>> That's a good idea. I am in favour of it. We can do that in the
> section where
> >>> we describe the calendars.
> >>>
> >>>> 2. A standard mechanism for data producers to indicate that they have,
> >>>> in fact, taken the extra care with their time calculations,
> >>>> whichever calendar they may have chosen - that is, the elapsed time
> >>>> values are guaranteed to be free of any leap second related offsets
> >>>> or discontinuities. This would give data consumers greater
> >>>> confidence in cases where such errors matter.
> >>> Yes, I see the value in that. I wonder how we would do it. What comes
> to mind
> >>> is to suggest that they are making that guarantee by specifying CF-1.7
> (I hope
> >>> - or whichever version contains this change) rather than any earlier
> version,
> >>> which means in particular that the calendar will no longer have a
> default. If
> >>> they have changed their software to write CF-1.7 in the Conventions
> attribute,
> >>> we can hope that they have also changed it to be consistent with the
> new and
> >>> more precise definition of the calendar attribute. The changes made
> are listed
> >>> in an appendix to the standard (it will be Appendix Z in CF-1.7) and
> the
> >>> implication of this change should be made clear there. What else could
> we do?
> >>>
> >>> Best wishes
> >>>
> >>> Jonathan
> >>> _______________________________________________
> >>> CF-metadata mailing list
> >>> CF-metadata at cgd.ucar.edu
> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>
> >> --
> >> CICS-NC <http://www.cicsnc.org/> Visit us on
> >> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> >> *Research Scholar*
> >> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/
> >
> >> North Carolina State University <http://ncsu.edu/>
> >> NOAA National Centers for Environmental Information <
> http://ncdc.noaa.gov/>
> >> /formerly NOAA?s National Climatic Data Center/
> >> 151 Patton Ave, Asheville, NC 28801
> >> e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
> >> o: +1 828 271 4900
> >>
> >> /We will be updating our social media soon. Follow our current
> >> Facebook (NOAA National Climatic Data Center
> >> <https://www.facebook.com/NOAANationalClimaticDataCenter> and NOAA
> >> National Oceanographic Data Center
> >> <https://www.facebook.com/noaa.nodc>) and Twitter (_at_NOAANCDC
> >> <https://twitter.com/NOAANCDC> and _at_NOAAOceanData
> >> <https://twitter.com/NOAAOceanData>) accounts for the latest
> >> information./
> >>
> >>
> >
> >> _______________________________________________
> >> CF-metadata mailing list
> >> CF-metadata at cgd.ucar.edu
> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> >
> > ----- End forwarded message -----
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150520/5cb92f6a/attachment.html>
Received on Wed May 20 2015 - 09:44:48 BST
