Tim,
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
discussion.
Grace and peace,
Jim
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 _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/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>
Received on Mon Jun 29 2015 - 10:25:23 BST
