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

From: Jonathan Gregory <j.m.gregory>
Date: Thu, 11 Jun 2015 17:09:01 +0200

Dear Jim

> I appreciate your willingness to continue this attempt to find a
> meeting of the minds about all of this. I hope you will forgive me
> if I am not always completely clear in my attempts to express myself
> or fail to understand you.

I would say exactly the same to you! Thanks. Actually I'm struggling to
understand what we are disagreeing about.

> As a data consumer, all I have to do is convert the reference time
> from the stated calendar to my desired calender, then use that as
> the basis for producing timestamps from the elapsed times in the
> variable (using the correct set of time functions, of course).
> Expressing the elapsed times as timestamps in one calendar and then
> converting those timestamps to another is another way that you could
> do it, but one which adds unneeded steps.

In both our views, decoding the time coord (into components of time, which
I will refer to as "timestamps" for convenience although we would probably not
use strings for this purpose, since usually we want numbers) according to the
calendar stated by the attribute requires using the algorithm appropriate for
the calendar. This algorithm is one which can add an offset to the reference
timestamp using the rules of the calendar to produce new timestamps, and the
reverse. Hence the calendar attribute implies particular rules for encoding and
decoding. But that is the statement of mine which you disagree with, I think -
isn't it?

I agree that the calendar attribute also states the calendar in which the ref
time is expressed - this second function is one I have recognised because of
our discussion (it is obvious in the case of model calendars, so I didn't see
it as a distinct function). Since the att states the calendar of the ref time,
and implies the rules for encoding and decoding, it therefore also inevitably
implies the calendar of the decoded timestamps, doesn't it?

I agree that you could change to a new calendar in the real world by
calculating the difference in seconds between the ref time if it's interpreted
in the old calendar and if it's interpreted in the new calendar (or a new
ref time if you want to change the ref time as well as the calendar) and then
adjusting the time coordinates by this amount (and the ref time in the units
string if you want to change that as well). I think that will be the same as
what I suggested, which is to decode the coords using the old calendar and
ref time, then encode them using the new calendar and ref time. Perhaps my
method sounds like more calculation, but it might be easier to carry out (just
two subroutine calls). I think these methods are equivalent, aren't they?

They work because, as we agree, the encoded time coord is also an elapsed time,
and is useful as such. The only situation in which it might have small dis-
continuities is if the no-leap-second algorithm is used to encode and decode
UTC and, as we have agreed, there should be a clear warning against not doing
that if precision <1 min is required.

The reason that I regard timestamps as primary, and therefore suggest that one
would go via timestamps to change the calendar, is because of the non-real-
world calendars that are the subject of other emails. Although, as you rightly
say, there is no exact way to draw an equivalence between the real-world
and the various non-real-world calendars (360_day, no_leap, etc.), we have to
draw such an equivalence for model-model and model-obs comparisons. The main
purpose of CF is to clarify when and how data is to be regarded as comparable,
and it's a common need to compare climate data in different calendars. When
this is done, it's the timestamps which are comparable. DJF (season) is DJF
(including all of Dec, Jan and Feb) whichever calendar is used, even though it
has different lengths in those calendars. Therefore it is the timestamps which
truly define the ranges of time, not the relative time coordinates.

Best wishes

Jonathan
Received on Thu Jun 11 2015 - 09:09:01 BST