Maik,
I'm far from an expert on this, but doesn't this depend entirely on how
you choose to count your seconds? If you declare your time as 'seconds
since epoch', then it seems to me that it would be perfectly fine (and
perhaps most appropriate) to use exact seconds as defined by
International Atomic Time (TAI) since the epoch you define. I don't see
where using a UTC date/time string (along the lines of ISO8601) to
declare the epoch means you must use time-since-epoch values that
include leap seconds. The problem that you point up in your
netcdf4-python tracker issue is a problem with conversions between
date/time structures (sets of years, days, hours, minutes, and seconds)
and time-since-epoch values that are provided by a netCDF python module.
CF makes no assumptions about any of that.
In terms of CF, I think the question really comes down to an issue of
how people encode and decode time variables. If you create your
time-since-epoch values by subtracting two POSIX time values, then leap
second effects will be included. If you subtract two TAI time values to
create your time-since-epoch values, then leap seconds effects won't be
included. If someone decodes either of these into date/time structures
with a non-matching assumption about the type of time-since-epoch values
used, then a problem can arise. It seems to me that the CF convention
here is encoding agnostic.
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.
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
--
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/20140716/99283b9e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ehaggeaj.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140716/99283b9e/attachment-0001.png>
Received on Wed Jul 16 2014 - 09:04:38 BST
