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
Received on Wed May 20 2015 - 08:43:24 BST
