Hi all,
I haven't chimed in for a bit because others have been saying all the
things I would have said. I think Jonathan's take is dead-on, and I
agree pretty much completely.
Are there any other real-world time systems we need to be concerned
about, or would adding a distinction between proleptic_gregorian and
proleptic_gregorian_utc cover all the various leap-second issues?
And I hesitate to ask, but is there anything else weird like relativity
making clocks run at different speeds for satellite data that we ought
to be making space for in addition to the UTC vs GPS distinction?
Cheers,
--Seth
On 4/29/2015 7:39 AM, Jonathan Gregory wrote:
> 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
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Wed Apr 29 2015 - 10:00:39 BST
