In a similar position (of understanding) as John, I agree with him.
Karl
On 5/20/15 7:43 AM, John Graybeal wrote:
Without fully appreciating _all_ the particulars (sorry!), I think Jonathan's
diagnostic (that people would tend to keep using gregorian) is correct. 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).
john
On May 20, 2015, at 07:16, Jonathan Gregory <[email protected]> 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 <[email protected]> -----
Date: Wed, 20 May 2015 09:15:01 -0400
From: Jim Biard <[email protected]>
To: [email protected]
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
[email protected]
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: [email protected] <mailto:[email protected]>
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 (@NOAANCDC
<https://twitter.com/NOAANCDC> and @NOAAOceanData
<https://twitter.com/NOAAOceanData>) accounts for the latest
information./
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
