[CF-metadata] How to define time coordinate in GPS?

Jim Biard jbiard at cicsnc.org
Mon Jun 29 10:25:23 MDT 2015


I come to all of this from working with polar satellite data, where a 
difference of 1 second represents a geographic error of ~7 km, so I am 
sensitive to your concerns.

The very thing we are trying to make sure in this discussion is that 
whether you record your reference date and time as timestamps in UTC 
(with leap seconds) or GPS (without leap seconds), that you can tell the 
world that they can trust that the elapsed time values in your time 
variable are true elapsed seconds (or minutes, or milliseconds, etc). It 
is clear from a little thought experiment that the calendar attribute 
(under most circumstances, at least) is only telling me how to interpret 
my reference time. (I can build a data acquisition system that includes 
a synced clock and a highly precise time counter. When I acquire 
measurements, my system records the start date and time, starts the 
counter, and records the elapsed time each time I acquire a measurement. 
I can directly store all of this into a CF time variable, and for others 
to make proper use of it, all I have to indicate is base unit my elapsed 
time is in and what representation system was used for my reference date 
and time.) Is my reference clock a UTC clock or a GPS clock? Thus the 
different calendars under discussion - gregorian_utc and gregorian_gps. 
(These aren't the only possible calendars, either. There can be other 
calendars that use other time systems, such as TAI. They can be added as 
they are requested.) The gregorian_utc and gregorian_gps calendars are 
telling data consumers that you have error-free elapsed times and 
telling them how to interpret the reference date/time stamp.

The reality is that numerous data producers didn't acquire their elapsed 
times as in my thought experiment. Some started with UTC timestamps 
obtained from a synced source at each measurement time, and used 
software that wasn't aware of leap seconds (such as the Unix/linux suite 
of functions) as part of the calculations that produced their elapsed 
times. Depending on the choice of reference date and time, they 
introduced a possible offset into all of their elapsed time values, and 
if the range of times included a leap second boundary, they introduced a 
discontinuity part way through the elapsed time series.

Other data producers (modelers, for example) generated time stamps 
unconnected to the real motions of the real earth, then calculated 
elapsed times using software that wasn't aware of leap seconds. Which is 
fine. It's a model. In the model universe there are no leap seconds. But 
the time in the reference timestamp isn't UTC.

The thing is, most of these data producers are working with intervals on 
the order of minutes or longer. The errors that might be produced by 
misconstruing the reference timestamp or introducing offsets or 
discontinuities into the elapsed times are well below the "noise floor". 
The discussion about the gregorian_nls calendar and some other possible 
calendar (gregorian_utc_lse? - lse = leap second errors), as well as the 
discussion about what to do with interpretation of the existing calendar 
named gregorian is about how to handle these cases, since people without 
fine time resolution are likely going to continue to work the way they 
have been; and, indeed, there is no reason they should forced to change 
- using conversion software that is aware of leap seconds when your time 
interval is 0.5 days and your effective resolution is 0.01 days is overkill.

The CF community is becoming more and more diverse, and the challenge is 
to find ways to document the data that accommodates everyone reasonably 
well, "makes sense", and has intuitive power.

The conventions up through 1.6 used the term UTC, but was really using 
it as a shorthand for "a time system that is based on longitude 0 
degrees and puts midnight on that longitude at approximately the point 
where the longitude is facing directly away from the Sun." There wasn't 
really any thought of leap seconds involved at the time. We've gotten to 
the point where more precise definitions are required by some. Thus the 

Grace and peace,


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
> Any email message from EUMETSAT is sent in good faith but shall neither be binding nor construed as constituting a commitment by EUMETSAT, except where provided for in a written agreement or contract or if explicitly stated in the email. Please note that any views or opinions presented in this email are solely those of the sender and do not necessarily represent those of EUMETSAT. This message and any attachments are intended for the sole use of the addressee(s) and may contain confidential and privileged information. Any unauthorised use, disclosure, dissemination or distribution (in whole or in part) of its contents is not permitted. If you received this message in error, please notify the sender and delete it from your system.
> _______________________________________________
> 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

/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 @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and 
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150629/06e69819/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/06e69819/attachment-0001.png>

More information about the CF-metadata mailing list