On Wed, May 20, 2015 at 9:35 AM, Jonathan Gregory <j.m.gregory at reading.ac.uk
> wrote:
> > I understand that someone may have made a mistake/used an inappropriate
> > library, etc, such that there may be an off by-a-couple-seconds error in
> > the elapse time. But are we really trying to include something in the
> > standard to accommodate that?
>
> Yes! Most applications aren't sufficiently precise to care about this (and
> in the model world it doesn't arise), but there are some which care about
> the
> leap seconds, it appears.
I'm sure there are, yes. Though I would HOPE that people who should care
about leap seconds use appropriate tools! And I'm still unclear on what
role the CF standard should play in accommodating errors by data producers.
That's what motivated the original enquiry. In the
> real world UTC calendar (gregorian_utc), the leap seconds must be accounted
> for in order to calculate and interpret the elapsed time correctly. In the
> gregorian_nls calendar, they are ignored.
sure -- but I've got to wonder how often mistakes arise (that matter) --
the data producer is usually working in "real" time units anyway - i.e.
seconds since some epoch. Which is a good direct match for the CF encoding.
Sure, there are things like instrument data logs that use date-timestamps
in iso 8601 format or whatever -- and these need to be converted to
time-since-epoch -- but those are unlikely to care about leap-seconds.
It's really hard to imagine folks working with, say, GPS signals working
with datetime strings -- and if they do, they damn well better know what
they are doing.
> There could be errors / lack of precision in ANY variable in a file --
> > what's so special about this one?
>
> I think it's complicated because of the two representations of time, either
> as YMDhms, or as elapsed time. This complexity doesn't apply to other
> coords.
>
Maybe not -- but practically anything has its own issues -- datum for
lat-long, for instance -- that's pretty analogous
But I don't think that's a CF issue. For lat-lon, if the user specifies a
given CRS, but didn't actually do the conversion properly, should we have a
way to specify that? (and this is NOT a rare occurrence!)
I guess I'm suggesting that some more generic mechanism should be used to
specify the precision of the time data. Is there a standard way to specify
precision in CF that could simply be used? I don't know of one, but I've
only poked at the parts of CF I've needed.
Something like
time:precision = "3 seconds"
Anyway, probably no harm is done by adding this, it just feels "impure" to
me!
-Chris
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150520/ff89ecc9/attachment.html>
Received on Wed May 20 2015 - 11:04:29 BST
