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
