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

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 29 Apr 2015 14:39:50 +0100

Dear Jim, Chris et al.

I'm using the word "calendar" in a CF-consistent way, I believe. Maybe it's not
the best word for the concept, but nonetheless we have an attribute called
"calendar", and its sole function is indicate which algorithm is used to
translate between components of time (YMDhms) and elapsed time (in units of
time since a reference time). So perhaps that is consistent with "calendar"
being a collection of algorithms, in Chris's text, but it's more specific
than that. It has a particular function in the interpretation of CF time
values (usually coordinates). CF sect 4.4.1 says
"In order to calculate a new date and time given a base date, base time and a
time increment one must know what calendar to use."
and I think that is the sense in which I am using "calendar".

> In the "real" world, we often start with UTC timestamps that have
> leap seconds accounted for, yet convert them to elapsed times using
> calculators that don't account for leap seconds. This can actually
> lead to elapsed time values that encode a time discontinuity and
> cannot be counted on to produce accurate differences between every
> pair of values.

This is a problem, I agree. We should avoid that problem for future data by
making the conventions more precise about which calculator should be used
(which calendar, in the CF sense). We can't decide for sure what was done when
encoding past data, but the conventions string records the version of CF used.

> I'm suggesting that we need to do two things. One is to more precisely
> define what sorts of times can be used in the time reference part of
> the units attribute. I just reread section 4.4, and it actually says
> that the time is UTC or a time zone offset from it. I think it
> should stay that way and the wording strengthened to make it
> clearer.

Yes, it does say that. It's a quote from the udunits man page. However I don't
think the issue of leap seconds has been carefully considered before, so we
don't have to assume that's what it meant exactly, especially as udunits does
not support lead seconds. As previously said, and I think you may agree, it is
likely that nearly all existing time values have been encoded *without* leap
seconds, and therefore *not* UTC strictly. Therefore my alternative suggestion
is that we should add some text here that says we don't necessarily imply
leap seconds are included by mentioning UTC. This must be the case, because
the same format of time unit is used for calendars that definitely do not ever
include leap seconds i.e. all the non-real-world ones. UTC is mentioned simply
as a way to refer to the time-zone which contains the Greenwich meridian,
without summer time.

> The other thing I think we need to do is provide a way to indicate
> that the elapsed times in a time variable are true elapsed times
> that are certain to be free of leap second discontinuities, or are
> possibly contaminated with leap second discontinuities. In
> connection with this we would need to add clarifying language in the
> CF conventions to educate people on the importance of using time
> calculators that are aware of leap seconds when moving between UTC
> timestamps and elapsed time values. This could be handled by adding
> a modifier to a calendar name in the calendar attribute, or it could
> be handled by adding a new attribute to hold this information. I
> think that coming up with one or more new calendar names is a more
> confusing and less useful way to accomplish this.

I don't think we should define a new attribute, because this distinction is
one which applies only to the real-world calendar. It's therefore more robust
and simpler to indicate it as a modifier to the name when applicable in the
the calendar att, so making a new calendar name, in effect. But given this
discussion I agree that calling it just "UTC" may not be clear enough. The
real-world calendar is called "standard" or "gregorian". I would propose a new
possibility "proleptic_gregorian_utc", meaning the proleptic Gregorian
calendar with leap seconds inserted as applicable since 1958.

Best wishes

Jonathan
Received on Wed Apr 29 2015 - 07:39:50 BST