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

From: Jonathan Gregory <j.m.gregory>
Date: Tue, 19 May 2015 22:23:58 +0100

Dear Jim

> We are definitely getting much closer to full agreement. I continue
> to think that a separate time_system (or some such) attribute would
> be a much better way to handle this than modifying the calendar
> attribute, and that space-separated calendar modifiers would be next
> best after that, but I will bow to the apparent majority and agree
> to your proposal for modified definitions of the general reference
> time and Gregorian calendar, the addition of a new gregorian_utc
> calendar, etc, as you just outlined.

That is good news. I am glad that we understand things in a compatible way now
thanks to this discussion, and I am grateful for your flexibility and willing-
ness to compromise on the implementation.

> There are two remaining things that I would like to see.
>
> 1. A section that explains the importance for data producers and
> consumers of using the right time handling routines for the input
> time data and the calendar chosen if your time resolution makes you
> sensitive to errors on the order of 1-30 seconds, pointing out (for
> example) that using the standard *nix time functions with sets of
> correct UTC timestamps will produce incorrect elapsed time values
> under the right conditions. Such a section would also point out to
> data consumers that if errors on this level are significant to them,
> they shouldn't assume that existing observational datasets are free
> of these errors.

That's a good idea. I am in favour of it. We can do that in the section where
we describe the calendars.

> 2. A standard mechanism for data producers to indicate that they have,
> in fact, taken the extra care with their time calculations,
> whichever calendar they may have chosen - that is, the elapsed time
> values are guaranteed to be free of any leap second related offsets
> or discontinuities. This would give data consumers greater
> confidence in cases where such errors matter.

Yes, I see the value in that. I wonder how we would do it. What comes to mind
is to suggest that they are making that guarantee by specifying CF-1.7 (I hope
- or whichever version contains this change) rather than any earlier version,
which means in particular that the calendar will no longer have a default. If
they have changed their software to write CF-1.7 in the Conventions attribute,
we can hope that they have also changed it to be consistent with the new and
more precise definition of the calendar attribute. The changes made are listed
in an appendix to the standard (it will be Appendix Z in CF-1.7) and the
implication of this change should be made clear there. What else could we do?

Best wishes

Jonathan
Received on Tue May 19 2015 - 15:23:58 BST