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@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: jbi...@cicsnc.org
o: +1 828 271 4900
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
