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 @NOAAOceanData
<https://twitter.com/NOAAOceanData>) accounts for the latest information./
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150520/74a1b37c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150520/74a1b37c/attachment-0001.png>
Received on Wed May 20 2015 - 07:15:01 BST
