Nan,
GPS time didn't exist, as such, before 1980-01-06 (year-month-day). It
is a continuous count from the reference date and time of 1980-01-06
00:00:00 using the Gregorian calendar and the UTC time system. UTC
started using leap seconds in 1972. Before that UTC was being adjusted
by small arbitrary amounts on much shorter time scales than the current
"a couple of times every three years or so" scale. To refer to times
prior to 1980-01-06 with the GPS time system, you would be using a
"proleptic" version, and leap seconds would still matter.
I like the idea of recording the time resolution or uncertainty. I think
this could help signal to data consumers that you took the trouble
needed with leap seconds, etc to achieve a certain level of accuracy and
precision.
Grace and peace,
Jim
On 6/29/15 11:56 AM, Nan Galbraith wrote:
> Hi Tim -
>
> I don't think there's any difference between GPS and UTC times
> before 1981-07-01, when the first leap second was accepted (if that's
> the right term), so, if your reference time is before that date, you
> can use the GPS calendar attribute, and not worry about it being used
> to muck with your reference date.
>
> I've argued that 'instrument and measurement datasets' generally have
> time values that can't be accurate enough to care about leap seconds,
> and you've expressed the opposite view. To be honest, my instrument
> clocks are mysterious, at best, and I often have to override them. Then,
> to top things off, I use Matlab to generate elapsed time for CF, and have
> no clue whether that software knows anything about leap seconds.
>
> Maybe an uncertainty attribute should be a best practice for time
> variables;
> OceanSITES recommends doing that, but I'm not sure often it's included
> - or
> noticed by data users.
>
> Cheers - Nan
>
> On 6/29/15 6:16 AM, Timothy Patterson wrote:
>> I understand that for climate or forecast data that 30+ seconds of
>> inaccuracy may not be significant, but even though the C and F in "CF
>> Conventions" stand for "Climate and Forecast", the conventions are
>> also being increasingly adopted for instrument and measurement
>> datasets. In these cases, time accuracy at small time scales becomes
>> more important, which is why seeing a proposed convention that allows
>> the time to be written ambiguously (so that there may or may not be
>> discontinuities or offsets) is rather disconcerting, like telling a
>> climate scientist that the netCDF encoding of his temperature data
>> may or may not have introduced an inaccuracy of a few Kelvin in some
>> readings.
>>
>> Under the CF1.6 conventions, I believe the base time or epoch time
>> was always expressed in UTC and the calendar attribute was applied to
>> the encoded time count. Using this convention, I could specify a UTC
>> start time and then have a simple GPS-like count of elapsed seconds
>> (with no discontinuities introduced by leap seconds). Under the
>> proposals for the 1.7 convention, this doesn't seem possible. The
>> epoch and time count must both be expressed either as UTC or as GPS
>> time and the only "mixed calendar" options introduce the above
>> mentioned ambiguity.
>>
>> Regards,
>>
>> Tim Patterson
>
>
--
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
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150629/b2b6ee7f/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/20150629/b2b6ee7f/attachment-0001.png>
Received on Mon Jun 29 2015 - 10:38:21 BST
