John,
I'm afraid that your response has confused me quite a lot. If you don't
mind, please clarify what you mean by "udunits does not support leap
seconds". TAI does not use leap seconds. It is a running count of
seconds since Jan 1, 1958 00:00:00 UTC. UTC time messes around with leap
seconds in order to account for the fact that a day is not exactly
864000 seconds long, and that the rotation rate varies over time. The
leap seconds are used to keep time/date "strings" synchronized to the
diurnal cycle, much the same way that leap days are used to keep date
strings synchronized to the Vernal Equinox.
I think this problem may have more to do with the conversion from
time/date strings to counts of seconds and back than anything about the
counts of seconds themselves.
Grace and peace,
Jim
A true count of seconds since an epoch matches the approach of TAI, not UTC.
On 7/16/14, 5:58 PM, John Caron wrote:
> 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
> <mailto: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 <mailto:CF-metadata at cgd.ucar.edu>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140717/8397ad81/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cjiagfeb.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140717/8397ad81/attachment-0001.png>
Received on Thu Jul 17 2014 - 07:14:56 BST
