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/09442735/attachment.html>
Received on Wed Jul 16 2014 - 15:58:57 BST
