Tim,
Actually the only place where leap second artifacts should ever show up
is in the reference timestamp in the units attribute. The values within
a time variable are elapsed time counts since the reference date & time
and *should* always be free of leap second artifacts.
If the reference timestamp is a UTC timestamp, then it it will be
different from a TAI or GPS timestamp (or whatever other time system you
wish to use) by some number of seconds, in the same way that a Gregorian
date will be different from a Julian date by some number of days. The
"problem" is that CF, in the past, hasn't really considered the question
of which time system was used for the reference timestamp. It's
analogous to a situation where we hadn't gotten around to considering
the question of which calendar was used for the reference date. As long
as we were all using the same calendar, it didn't really matter.
The issue gets more complicated because it's all too easy to mistakenly
introduce errors into the elapsed time counts because most time handling
libraries don't handle leap seconds. (This is at least partly because
there is no regular rule for when to apply one.) It can be like using a
date handling library that only knows about Julian dates to get elapsed
days from Gregorian dates.
Grace and peace,
Jim
On 5/20/15 1:47 PM, Timothy Patterson wrote:
> From my (perhaps naive!) viewpoint, it seems the convention is trying to use a single "time" variable to encode two different concepts; the simple "elapsed time" since a given time-zero, monotonically increasing without discontinuities, in line with all other measurement variables like distances, temperatures, etc.); and an encoded "look-up-table" or "date" into which leap second discontinuities are inserted at random junctures and which may not even be defined outside certain boundaries.
>
> I expect that any request to define, say, a temperature variable in this way - sometimes in units of Kelvin and sometimes in a different measurement system which jumped certain temperature values - would be quickly dismissed, but the current proposals for the time variable all seem to be advocating this approach instead of perhaps reserving "time" for storing the actual count of seconds, analogous to all other CF coordinate measurements, and introducing a separate "date" variable for those who want to encode whatever discontinuous, non-linear date system they choose.
>
> I should note that this proposal might not be fully backwards compatible (i.e. it's probably entirely incompatible).
>
> Regards,
>
> Tim
>
> Any email message from EUMETSAT is sent in good faith but shall neither be binding nor construed as constituting a commitment by EUMETSAT, except where provided for in a written agreement or contract or if explicitly stated in the email. Please note that any views or opinions presented in this email are solely those of the sender and do not necessarily represent those of EUMETSAT. This message and any attachments are intended for the sole use of the addressee(s) and may contain confidential and privileged information. Any unauthorised use, disclosure, dissemination or distribution (in whole or in part) of its contents is not permitted. If you received this message in error, please notify the sender and delete it from your system.
> _______________________________________________
> 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 National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA?s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
o: +1 828 271 4900
/We will be updating our social media soon. Follow our current Facebook
(NOAA National Climatic Data Center
<https://www.facebook.com/NOAANationalClimaticDataCenter> and NOAA
National Oceanographic Data Center <https://www.facebook.com/noaa.nodc>)
and Twitter (_at_NOAANCDC <https://twitter.com/NOAANCDC> and @NOAAOceanData
<https://twitter.com/NOAAOceanData>) accounts for the latest information./
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150520/054e7007/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150520/054e7007/attachment-0001.png>
Received on Wed May 20 2015 - 15:05:35 BST
