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

From: Jonathan Gregory <j.m.gregory>
Date: Tue, 14 Jul 2015 18:48:14 +0100

Dear Karl

Thank you for your useful summary, which I think is quite right. That will
provide some good text for the standard document.

You suggest merging gregorian_nls (for models, exactly 86400-second days)
into gregorian (imprecise about which calendar is used and how encoded),
distinguishing them according to whether the data is model or observational.

I'm not comfortable with that. I can't think of another case in CF where the
metadata is designed to be interpreted differently for models and observations,
and it would not be easy to do, because there's no metadata that is guaranteed
to be present in a standard form to tell you if it's model or observational.
Yet I think this distinction must be made. It would not be satisfactory if
users interpreted the imprecision of "gregorian" to mean they could decode
model data e.g. from CMIP using the UTC calendar, and found days that appear to
start 16 seconds different from midnight. I am sure this would cause problems
e.g. wrong months selected. That's why I think we need gregorian_nls as a model
calendar, to be used instead of gregorian in future where applicable. We need
to be able to assert that the 86400-second day definitely applies.

I agree with Jim that there is a distinction between gregorian_utc_nls and
gregorian too. Some people supplying observational data don't require the
precision of specifying UTC (or GPS), so they don't want to choose gregorian_
utc or gregorian_gps. Nan argued this case. Others however may wish to be
precise about UTC timestamps, but choose to encode it without leap seconds.
So I think we need the meaning of gregorian_utc_nls.

However, on reflection I convinced myself (at least! - but not Jim) that the
distinction between gregorian_nls (for models) and gregorian_utc_nls (for
the real world) is too subtle to make reliably, so I suggested we should use
gregorian_nls for both, and say that *if* it is observational data, it must
be UTC. That's not quite the same as your suggestion, because the timestamps
can be exactly recovered without knowing if it's model or observational, but
you would need to know in order to tell whether the elapsed times are accurate
(as they are for model data) or perhaps not accurate (for real world data).
Whereas I regard timestamps as more important, Jim tends to regard elapsed
times as more important, so I guess this second issue would count more for him.
If it is crucial, then we need both gregorian_nls and gregorian_utc_nls. The
distinction is whether it is model or real-world time. My concern is that when
when models are used to simulate events that happened in real-world time, data-
producers may often find it hard to decide between these alternatives, and it's
unclear whether it's useful to do so anyway.

Best wishes

Jonathan
Received on Tue Jul 14 2015 - 11:48:14 BST