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
