John,
I think you grok correctly in the first case. In the second case, the
timestamp produced by many GPS units does not have any leap second
corrections, so it will be 16 seconds off from UTC (until July 1, 2015,
when it will start being 17 seconds off). The definition of GPS time is
weeks and seconds since the GPS epoch (1980-01-06 00:00:00) without
regard for leap seconds. It is a true elapsed time. Most (if not all)
units don't have leap second files in them (partly because you'd have to
keep updating them), so they produce time stamps that are not UTC. If
your data comes from a computer that keeps its internal clock updated
with Network Time Protocol, the timestamps you get do have leap second
corrections. Many satellite systems generate proper UTC timestamps. So
it depends on where you are getting your timestamp from.
Also, keep in mind that what we store is elapsed time since the epoch
defined in the units attribute. Even if the reference time in the units
attribute is UTC and your timestamps were all UTC (thus including leap
seconds), as long as the entire span of time from your reference time to
your last timestamp does not include a leap second event your elapsed
times will be true elapsed times whether you used a leap-second aware
calculator or not. (The errors cancel when you take the difference.)
Grace and peace,
Jim
On 4/29/15 11:50 AM, John Graybeal wrote:
I've been having trouble following some of the language, and so I want
to start by citing this snippet as a clear description of current
practice:
On Apr 28, 2015, at 14:41, Jim Biard <[email protected]
<mailto:[email protected]>> wrote:
In the "real" world, we often start with UTC timestamps that have
leap seconds accounted for, yet convert them to elapsed times using
calculators that don't account for leap seconds. This can actually
lead to elapsed time values that encode a time discontinuity and
cannot be counted on to produce accurate differences between every
pair of values.
Assuming I grok reality, I agree that the historical default for
existing datasets is that the leap second handling has to be
"unknown", as it all depends on the conversion software.
With this as my baseline, I am not sure how to interpret the following
sentence:
On Apr 29, 2015, at 06:39, Jonathan Gregory <[email protected]
<mailto:[email protected]>> wrote:
it is likely that nearly all existing time values have been encoded
*without* leap seconds, and therefore *not* UTC strictly.
Let me take an example: A sensor system has a GPS, and timestamps its
data accordingly. As I understand it:
* the GPS timestamp is using UTC; and
* the UTC has included any leap seconds that have been added since
leap seconds began. (Must be true, or GPS timestamps would be 16
seconds off, right?)
So it seems to me almost all observational time values have been
encoded *with* leap seconds, and therefore *are* UTC.
Can Jonathan or others clarify what I've got wrong?
John
_______________________________________________
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
