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