Chris,
On 5/12/15 11:52 AM, Chris Barker wrote:
On Mon, May 11, 2015 at 11:58 AM, Jim Biard <[email protected]
<mailto:[email protected]>> wrote:
I agree that in many cases the implications of mistakes in which
calendar and/or time system was used when creating or using a
given file are often negligible.
there is that...but that wasn't my only point.
This is one of those situations where it most often doesn't really
matter, but it sometimes can matter a lot. If you are working with
1 km resolution data from a satellite that is moving at ~7 km/sec,
then even a 1 second discrepancy is significant. If the time span
over your full set of files is long enough that a leap second
event is included, then even time differences taken between points
within your set of files can be wrong.
sure, but if you choose your epoch carefully (or even have the same
epoch in all your files) then whether this is a problem is a function
of how you work with the time axis in the client -- no how it it is
encoded in the file.
I guess what I'm getting at is that the choice of "time since an
epoch" encoding really does make all this safer.
I disagree somewhat with what you've said above. In the admittedly small
number of cases where it matters, the question of what exactly was
encoded in the file is quite relevant. In one of these cases, if a
producer has managed to insert some number of seconds of absolute offset
and/or some number of 1 second discontinuities into the values in a time
variable because he didn't handle a set of input times carefully enough,
a trap has been set for users who may not be able to tell that there is
a problem without a deep dive into the data (if even that will disclose
it). This is particularly true if the user is trying to do more than
produce time labels for plots.
That being said:
Because this is something that is often insignificant, I proposed
a combination clarified definitions, and additional attributes
and/or optional modifiers to calendar names that allow for greater
precision when it matters without sacrificing backward
compatibility for large numbers of datasets.
Exactly -- better precision in the definitions is only a good thing --
but I think we can relax about older files (and older CF versions)
being ambiguous -- anyone for whom it matters should know how to deal
with it.
The problem for those for whom it matters is not being sure of what they
have and whether or not they need to take corrective action. Of course,
there's nothing we can do for existing datasets that have problems other
than make it clear in documentation that monsters may be lurking.
It's precisely because this issue is rare that I suggested adding
clarifying text to the time section in the conventions, clarifying
existing calendar definitions, and adding new attributes or calendar
name modifiers rather than coming up with new calendar names and
deprecating old ones. Because there are a lot of people that won't ever
be affected by mishandled leap seconds.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[email protected] <mailto:[email protected]>
Grace and peace,
Jim
--
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
