Hi Jim > I see where the potential for mismatches when using time values with > "unexpected" encoding means that we should provide a way to declare what > kind of time-since-epoch values are used in a particular time variable.
And that's exactly the problem. The CDF website summarizes it quite nicely: "Science data should have well-defined times to enable more accurate cross-comparison between missions and as documentation for future archive use." netcdf-CF is basically CDF before introduction of the CDF_TIME_TT2000 type. In the end, people use libraries to read datasets, and I'm pretty sure that the netcdf4 library in Python is used a lot, and this one assumes a certain time encoding, without actually having it specified within the CF conventions. And I find this all a bit worrying, but many people probably don't care as their time resolution is higher than 1 second. Still, I think this issue should be addressed, better sooner than later. Don't you think? Cheers Maik > > Grace and peace, > > Jim > > On 7/16/14, 4:06 AM, Maik Riechert wrote: >> Hi, >> >> after reading >> http://cdf.gsfc.nasa.gov/html/leapseconds_requirements.html I'm a bit >> confused on how CF handles times for the netcdf world. It seems as if >> the 'seconds since' convention is basically POSIX time in regards to >> how leap seconds are handled. Quoting wiki " Due to its handling of >> leap seconds, it is neither a linear representation of time nor a true >> representation of UTC". This means that any dataset with <= 1 second >> resolution which covers the moment a leap second happens will have a >> problem encoding the time using the existing units convention. >> >> I first posted this issue on the netcdf4-python tracker: >> https://github.com/Unidata/netcdf4-python/issues/280 >> >> Is this an issue which was discussed before and is there any solution? >> >> Cheers >> Maik _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
