Jonathan,
I see where you are coming from, and there's validity in that line of
thought. Leap seconds represent a finer-grained adjustment to the
overall date/time system being used. I still think it makes good sense
to add a new attribute to declare whether or not leap second handling
was used or strengthen our standards for time variables so that problems
are averted.
From a human understandability perspective, a calendar attribute of
"GPS" or "UTC" will be somewhat confusing. In my experience, people
don't speak of the UTC calendar, it's UTC time. Further, TAI and GPS
time don't really concern themselves with anything but counts of seconds
since an epoch date & time. People convert the counts to time stamps for
convenience, but they are actually more equivalent to the Julian Day
Number (JDN) than they are to the Gregorian or Julian calendar. TAI and
GPS time have different epochs, and TAI is more accurate, but they both
are running counts of seconds that aren't tied to the motions of the
Earth. As a result, I think that it's improper to talk about a GPS
calendar or TAI calendar.
What is being exposed by this discussion is the reality that any of us
(myself included) have often ignored or been unaware of the fact that
the time calculators (time handling software) we used when filling our
time variables with elapsed times weren't giving us true counts of
seconds since the epochs we wrote into our units attributes. If you are
working at a resolution of days or hours, this will probably never cause
a problem. If you are working at a resolution of minutes or less and
working over a time span of greater than two years, it may well have
caused at least occasional small problems. If you are working with
full-resolution polar-orbiting satellite data, one second represents ~7
km of satellite motion, so such errors can produce significant
geolocation errors.
A set of elapsed seconds since a Gregorian/UTC epoch that were
calculated from Gregorian/UTC time stamps without regard for leap
seconds and which crossed a leap second boundary are not "GPS" seconds.
Nor are they "UTC" seconds. They are, strictly speaking, elapsed times
into which one or more step errors have been introduced. As I mentioned
in a previous email, as long as you use the same time calculator to
extract time stamps as you did to get elapsed times from input time
stamps, you won't notice anything. You may notice a problem if you are
taking differences between elapsed times and a leap second boundary gets
involved.
As I've considered all of this more, I'm tending to favor the second
option I suggested.
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".
Clearly, having epoch time stamps with time zone offsets from UTC, as
described in the CF conventions, would be OK as well. I'm also open to
other namings for the new attribute and for its possible values. The
leap seconds only become an issue in certain rather specific instances,
so I think that such an attribute, along with a bit of discussion in the
document, would likely be sufficient to warn those people that may find
themselves negatively affected by improper leap second handling.
Grace and peace,
Jim
On 4/27/15 1:07 PM, Jonathan Gregory wrote:
Dear Jim
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.
I think this is a calendar issue because the calendar is the set of rules
which translate between components of time (YMDhms) and elapsed time (in
fixed time units) since the reference time. Your later email seems to me
to be consistent with that. In the real world, the elapsed interval (expressed
e.g. as the number of seconds) between the ref YMDhms and the actual YMDhs
depends on whether your calendar includes leap seconds (UTC) or not (GPS).
It seems that GPS is the calendar likely to have been assumed in existing
CF datasets, so it would be logical to say that the default is the real-
world calendar without leap seconds. Have I misunderstood something? If we
regard this as a property of the calendar, we don't need a new attribute.
Best wishes
Jonathan
_______________________________________________
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
