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
[email protected]
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: [email protected] <mailto:[email protected]>
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 (@NOAANCDC <https://twitter.com/NOAANCDC> and @NOAAOceanData
<https://twitter.com/NOAAOceanData>) accounts for the latest information./
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
