Chris,
On 5/12/15 11:52 AM, Chris Barker wrote:
> On Mon, May 11, 2015 at 11:58 AM, Jim Biard <jbiard at cicsnc.org
> <mailto:jbiard at cicsnc.org>> 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
>
> Chris.Barker at noaa.gov <mailto:Chris.Barker at noaa.gov>
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: 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/20150512/6cf33d74/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/20150512/6cf33d74/attachment-0001.png>
Received on Tue May 12 2015 - 11:02:41 BST
