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

From: Jonathan Gregory <j.m.gregory>
Date: Mon, 13 Jul 2015 11:18:53 +0100

Dear Jim and Karl

Thanks for your emails.

To Jim, I think I spoke too soon! I do agree that it's better to be precise,
but I'm concerned on reflection that there are two uses of real-world time
encoded as if there were no leap seconds in the real world:

* Observational data or models run with observational input, where the data
is timestamped in UTC, but encoded as coordinates without leap seconds. This
is what we agreed to call gregorian_utc_nls. In this case we pretend that the
real world has a constant day-length and no leap seconds.

* Models run to resemble the real world, with the real-world calendar and the
intention to compare actual weather or climate with model output, but without
leap seconds. CMIP5 historical and AMIP experiments are in this category, for
which some models use the real-world calendar (but no leap seconds), and some
of the input (for instance SSTs and atmospheric composition) refers to the
real-world calendar. However it is model data, and the model definitely does
not have leap seconds, so cannot truly be UTC at all. It actually is running
with a constant day-length. Thus we can't rightly call this gregorian_utc_nls.
It would be more accurate to call it gregorian_nls (not UTC, not GPS).

However the distinction between gregorian_utc_nls and gregorian_nls is very
subtle. I can barely see it myself, even when writing about it! I expect it
would not reliably be made by data-producers. Therefore I'd like to revert to
gregorian_nls for both cases. I think this only applies to UTC really. GPS
does not have leap seconds anyway, so a special no-leap-second encoding would
only be needed if you put a reference time for GPS before the GPS epoch. Maybe
we should disallow that, to avoid this ambiguity.

Therefore, with apologies, I have to ask the opposite question of whether you
could live with gregorian_nls to mean encoded UTC when it's truly real-world
data. I don't think it's satisfactory to call it just "gregorian" because we
have also recognised the need for a deliberately imprecise situation, when it's
not known if it's GPS or UTC or how encoded. gregorian_nls is precisely 86400-
second days, encoded as such, by intention.

Karl, do you have any comments about this?

Karl, I agree with your analysis. Jim and I also discussed ways of changing
the calendar, and we decided it wasn't essential to the definitions as such
to say how you could do it. Another possibility for changing from UTC to GPS
or v-v is to alter the reference time and its calendar so it refers to the
same instant in the real world. Then you don't need to alter the encoded time
coords. For changing between real-world and model calendars, I would argue that
they are only related via timestamps in principle (that is, January is the same
in both sorts of calendar only because it's regarded as January and comparable
for that reason), and the simplest way to convert is to decode the coords to
timestamps in the old calendar and reencode in the new calendar.

Best wishes

Jonathan
Received on Mon Jul 13 2015 - 04:18:53 BST