Jonathan,
I think the answer depends rather heavily on the way people obtained
their elapsed times that they stored in their time variables. If they
started with time stamps and the conversion to and from elapsed times
was done with software that doesn't consider leap seconds, then the
recovered time stamps will be correct, whether they represent UTC, GPS,
TAI or something else. The problems arise when your input is elapsed
times that don't contain leap seconds (such as GPS or TAI), or when a
different scheme is used for conversion from a time stamp to an elapsed
time than for conversion from an elapsed time to a time stamp.
Given that most of our time conversions from time stamps to elapsed
times haven't taken leap seconds into account up until now, the elapsed
times in these cases *are* encoding leap seconds if the time stamps were
UTC. They aren't being reduced to true elapsed time since an epoch.
By the way, modern *nix systems provide a means to have your system
account for leap seconds when converting to and from time stamps to
elapsed times, so *nix elapsed times on some systems could be true
elapsed times. (Wheee!)
I don't think calendars are the right place to encode this. We could add
a new "time_system" attribute where you would declare whether your time
stamps and elapsed times were based on UTC, GPS, TAI, etc. If we take
this route, we should require the elapsed times to encode leap seconds
if the time system is UTC, and state that the default time system is UTC.
We could also be more strict, and say the epoch time stamp in the units
attribute must always be in UTC. The question would then be reduced to
whether or not leap seconds were counted into the elapsed times stored
in the time variable. In this case, we could add a "leap_seconds"
attribute which would have a value of "UTC" if UTC leap seconds were
counted into the elapsed times, and "none" if not. This would also allow
for some other system of leap seconds to be used. (I don't know if there
are others.) For backward compatibility, considering history, the
default value for this attribute would probably be "UTC".
Grace and peace,
Jim
On 4/24/15 12:26 PM, Jonathan Gregory wrote:
Dear all
Thanks for these interesting contributions. In CF terms, it seems that UTC and
GPS time are different calendars, because of the leap seconds in UTC. A given
YMDhms date-time will sometimes be a different number of time-units since
reference-time in the two calendars. We ought to clarify the CF document, which
current assumes that the default calendar (the real-world Julian/Gregorian one)
is UTC for modern times. Since udunits and most software doesn't support leap
seconds, as Seth says, maybe we should amend the document to point out that
the default calendar is not exactly UTC because of this, and note that it has a
fixed offset to GPS time. Then we would need to introduce a new calendar of
utc, valid only for dates since UTC was defined. We could do it the other way
round, and define the default as UTC, but that would probably not be right for
(nearly) all existing data, and not convenient for (nearly) all software. Is
this correct?
Best wishes
Jonathan
----- Forwarded message from Seth McGinnis <[email protected]> -----
Date: Thu, 23 Apr 2015 13:06:21 -0600
From: Seth McGinnis <[email protected]>
To: [email protected]
Subject: Re: [CF-metadata] How to define time coordinate in GPS?
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0)
Gecko/20100101 Thunderbird/31.6.0
Julien,
I would say that you don't need to do anything. Your data is already in
GPS time.
Strictly speaking, you can't specify a different time referential,
because CF says to specify the time units following the recommendations
of udunits, and udunits assumes that all times are relative to UTC.
HOWEVER, udunits ignores leap seconds, and time under CF is represented
as a continuous count of constant-size units from some starting point.
Which I believe means that although both spec documents say "UTC", in
practice CF-netcdf is actually representing time as GPS/TAI time instead.
Moreover, as far as I can tell, practically all the software out there
that converts netcdf times to dates is unaware of leap seconds anyway,
and even if you wanted them you would have to do extra work to get them.
So I think if you set the units attribute as given in your example,
you'll be fine. If you want to be extra-careful, you could annotate the
time variable with a "note" attribute indicating that it's GPS time, not
UTC time, with no leap seconds.
There was a discussion on the mailing list about leap seconds last July:
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2014/057556.html
Cheers,
--Seth
On 4/23/15 8:19 AM, Julien Demaria wrote:
Dear Jonathan,
I?m also not an expert on this:
?GPS, Global Positioning System time, is the atomic time scale
implemented by the atomic clocks in the GPS ground control stations and
the GPS satellites themselves. GPS time was zero at 0h 6-Jan-1980 and
since it is not perturbed by leap seconds GPS is now ahead of UTC by 16
seconds.?
http://www.leapsecond.com/java/gpsclock.htm
a more detailed explanation:
https://confluence.qps.nl/display/KBE/UTC+to+GPS+Time+Correction
Thanks in advance,
Julien
Jonathan Gregory j.m.gregory at reading.ac.uk
Thu Apr 23 07:58:09 MDT 2015
Dear Julien
Could you explain what the difference is between GPS time and UTC (for a non-
expert such as me)?
Thanks
Jonathan
*De :*Julien Demaria
*Envoy? :* jeudi 23 avril 2015 14:51
*? :* '[email protected]'
*Objet :* How to define time coordinate in GPS?
Hi,
I need to define a time coordinate variable which use the GPS time
referential instead of UTC, but I did not found how to specify this.
For the moment my variable look like this :
int64 time_stamp(rows) ;
time_stamp:standard_name = "time" ;
time_stamp:units = "microseconds since
2000-01-01 00:00:00" ;
time_stamp:_FillValue = -1L ;
Thanks in advance,
Julien
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
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
