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
Received on Wed Jul 16 2014 - 14:48:12 BST
