Seth,
I don't work with ancient or model data sets, so I can't speak to the
question of UTC relative to Gregorian calendars. It seems to me that
since we already assume UTC +- a time zone offset for the time stamp in
the units attribute, that my suggestion causes no new problem.
As I think about it, I have to say that I overstated the case regarding
encoding of leap seconds. If the span from your epoch time stamp to the
last time stamp in the period of record for your dataset does not cross
a leap second date, no leap second is encoded. The conditions necessary
for one or more leap seconds to be encoded are described below.
Here's how an elapsed time can encode one or more leap seconds. Let's
consider a set of UTC time stamps and how they compare with the GPS time
counter. I'm going to set my epoch date/time to be the GPS epoch of
1980-01-06 00.00.00.0, and look at UTC time stamps running over the span
from the epoch date to the present day. The first leap second after this
epoch occurred at 1981-06-30 00:00:00.0, and there have been 16 leap
seconds total over the span from the epoch to the present day. If I use
time handling functions that don't consider leap seconds to convert
between time stamps and elapsed times (counts of elapsed seconds since
my epoch), I will find that the elapsed times calculated from my UTC
time stamps will match the GPS time count until that first date when a
leap second is encountered. After that date, my calculated elapsed times
will be less than the GPS time count by 1 second. If I had data at 1
second granularity, I would find that there are actually two UTC time
stamps at the time the leap second is applied that produce the same
elapsed time value. (This means that a time variable using these values
would actually fail the requirements for a true coordinate variable,
since the values wouldn't be monotonic.) After each leap second date the
elapsed time calculated from UTC time stamps would fall another second
behind the GPS time count. For a UTC time stamp of 2015-04-27 00:00:0.0,
the UTC-based elapsed time value would be 16 seconds less than the GPS
time count.
Grace and peace,
Jim
On 4/24/15 3:54 PM, Seth McGinnis wrote:
> Jim--
>
> Your suggestion in the last paragraph won't work. UTC is only
> meaningfully defined for the real world, so the epoch timestamp in the
> units attribute can only be UTC if the calendar is Gregorian...
>
> I'm a bit confused by the way you talk about elapsed times. It seems to
> me that elapsed time should be completely independent of the calendar
> and the time system. I view the time coordinate as the number of
> seconds (minutes/hours/days) that a hypothetical idealized clock
> attached to whatever's generating the data would count from the epoch
> marker, regardless of what the calendar is doing. An elapsed time would
> then be the difference between two time coordinates. The calendar and
> time system tell you what dates correspond to the endpoints of that
> interval, but they have no effect on its length. Could you elaborate on
> how an elapsed time would encode a leap second?
>
> Cheers,
>
> --Seth
>
>
> On 4/24/15 1:22 PM, Jim Biard wrote:
>> 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 <mcginnis at ucar.edu> -----
>>>
>>>> Date: Thu, 23 Apr 2015 13:06:21 -0600
>>>> From: Seth McGinnis <mcginnis at ucar.edu>
>>>> To: cf-metadata at cgd.ucar.edu
>>>> 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
>>>>> *? :* 'cf-metadata at cgd.ucar.edu'
>>>>> *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
>>>>> CF-metadata at cgd.ucar.edu
>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>>>
>>>> _______________________________________________
>>>> CF-metadata mailing list
>>>> CF-metadata at cgd.ucar.edu
>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>> ----- End forwarded message -----
>>> _______________________________________________
>>> 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./
>>
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
> _______________________________________________
> 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/20150427/8c5f3c12/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/20150427/8c5f3c12/attachment-0001.png>
Received on Mon Apr 27 2015 - 08:53:08 BST
