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

From: Jonathan Gregory <j.m.gregory>
Date: Fri, 12 Jun 2015 18:30:08 +0200

Dear Jim

It appears that we have some irreconcilable differences in interpretation but
I am not sure that they make any difference in practice, which is fortunate
if correct.

> The definition of a calendar includes (by implication) the rules for how
> to convert between an elapsed time count since a reference epoch and
> a timestamp as expressed in that calendar.
Yes. The elapsed time count is the time coordinate. That's what I mean by the
rules for encoding and decoding. In addition, the calendar attribute states
the calendar of the reference time. (I can't understand why taking these
together doesn't mean that the attribute implies the calendar of the decoded
timestamps too, but I don't mind if we don't say that! I've always assumed
that the calendar is regarded as a property of the time coordinate construct
as a whole, because it's an attribute of the time coordinate variable.)

Yes, I agree that you can change the calendar without modifying the time
coordinate values if you instead alter the reference time so that it refers
to the same instant of real time in the new calendar. (I was considering the
case when you wished to keep the same reference time, say 1st Jan 2015, but
alter the calendar. In that case you have to add an offset to the coordinate
values, which can be done be decoding and reencoding or by other means, but
the method used isn't material to the definition, so there is no need to say
how this is done.)

> Matching timestamps without conversion is exactly what you would
> *not* want to do when comparing observations recorded using two
> different real-world calendars.
That is true. But it is exactly what you do want to do when comparing real-
world and model calendars, or different model calendars, which is the common
case for a lot of CF data. In that common case, the timestamps are primary.
For example, climatological means, for which we have a CF conversion, assume
that users want to deal with time in a timestamp-based way, in which months
are equivalent regardless of calendar. It is inexact in a sense, but it's what
we need to do. More generally, you could argue that CF is quite a lot concerned
with the general problem of comparing apples and quinces. CF provides metadata
which enables users to indicate that the comparison is valid, by giving the
two things the same label.

I don't think the question of whether timestamps are primary makes a material
difference to the convention or its use. It would be fine to state that the
encoded time coordinate is an elapsed time and has no discontinuities, except
for small ones in the case of using the no-leap-second calendar to encode UTC
time. I think we have to support this case because it is almost certainly in
use, perhaps widespread use, and it's better to be explicit about it. CF does
not generally try to tell people what to do, but to enable them to describe
clearly what they have done.

I agree that seconds are always the same length. If only days were too! (But
they are in udunits, so we could warn against using days as a unit of time
in calendar="gregorian_utc" because it could be confusing, although encoding
and decoding would work correctly.)

Best wishes

Jonathan
Received on Fri Jun 12 2015 - 10:30:08 BST