Dear Mark:
About 6 weeks ago, I contacted the udunits support team because we needed
a unit of measure that was not currently supported, and they agreed to add
it.
They can be contacted at: support-udunits at unidata.ucar.edu.
very respectfully,
randy
----------------------------------------
From: "John Caron" <caron at ucar.edu>
Sent: Wednesday, July 16, 2014 5:59 PM
To: "Maik Riechert" <maik.riechert at arcor.de>
Cc: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Date/time and leap seconds
Hi Maik:
Unfortunately, CF references the udunits package which is no longer being
developed, at least for date/time coordinates.
udunits does not support leap seconds.
your best bet is to add an auxiliary time coordinate which uses leap
seconds, eg TAI. your specialized software can use that
also add a time coordinate which uses the standard non-leap seconds from
udunits. visualization software will use this to display calendar dates, i
think if you are careful this will only be wrong on a leap second.
You could propose adding a leap second-aware calendar to CF.
On Wed, Jul 16, 2014 at 2:48 PM, Maik Riechert <maik.riechert at arcor.de>
wrote: 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
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140716/28e0b9db/attachment.html>
Received on Wed Jul 16 2014 - 16:32:51 BST
