On Mon, May 11, 2015 at 11:58 AM, Jim Biard <[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. 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. -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]
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
