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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150520/b47dd354/attachment-0001.html>
Received on Wed May 20 2015 - 09:57:43 BST
