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 <jbiard at cicsnc.org
> <mailto:jbiard at cicsnc.org>> 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 <j.m.gregory at reading.ac.uk
> <mailto:j.m.gregory at reading.ac.uk>> 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
> 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/20150429/c14fd2a1/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/20150429/c14fd2a1/attachment-0001.png>
Received on Wed Apr 29 2015 - 12:19:33 BST
