On Wed, May 20, 2015 at 9:35 AM, Jonathan Gregory <[email protected] > 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 > [email protected] > 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 [email protected]
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
