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

From: Timothy Patterson <Timothy.Patterson>
Date: Thu, 11 Jun 2015 18:00:12 +0200

................Jim's Suggested Update...............

4.4.1 Calendar
In order to know what point in history has been measured by a given base date, base time, and time increment, one must know what calendar was used for the base date and time. The calendar attribute defines the particular date and time system that was used to express the reference time string found in the units attribute, and is assigned to the time coordinate variable. The values currently defined for calendar are:
...............................................

Although they aren't explicitly defined above, am I right to assume that using the standard units convention for time;

        time:units = "days since 1990-1-1 0:0:0" ;

the base date and base time correspond to the date/time string after the word "since" (1990-1-1 0:0:0) and the time increment corresponds to the units before the word "since" (days)?

Also that the calendar attribute would be applicable to the full units attribute - base date and base time and time increment.

Doesn't this conflict with the current convention in Section 4.4 where it is strongly implied that the base date and time are always supplied as UTC times?

Also, in Jonathan's last email he writes " 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."

We are trying to use the CF conventions for instrument data and in this case, we're looking for much greater precision than 1 minute so the difference between an encoded "timestamp" and an encoded "elapsed time" is important in our case.

Taking the suggested modified text at the start, would I be right in saying that the calendar modifier is also intended to modify the units. So applying a UTC calendar to "seconds since 1990-1-1 0:0:0" is in effect modifying the units to be "utc_seconds since 1990-1-1 0:0:0", meaning that this is counted on a discontinuous UTC time scale and not a continuous elapsed seconds time scale.

If my interpretation is correct, then this would remove the possibility of being able to specify a point in time in UTC and then have a true elapsed count (i.e. continuous rather than with UTC leap second gaps) since that time. Some of our products are currently using this method to compact the time data. By counting up from a recent event (i.e. the start of a scan line) rather than the start of year 2000 we can encode the data as a ushort of milliseconds instead of a double of seconds. The timestamp of the start of the scan line is expressed as a UTC (according to my understanding of the current conventions) and the units as milliseconds.

e.g. time:units = "milliseconds since 2015-06-11 17:51:22" ;

We then work in relative times as we 're not interested in expressing these time values as a calendar "timestamp".

Does this still work under the proposed scheme?

Regards,

Tim

Any email message from EUMETSAT is sent in good faith but shall neither be binding nor construed as constituting a commitment by EUMETSAT, except where provided for in a written agreement or contract or if explicitly stated in the email. Please note that any views or opinions presented in this email are solely those of the sender and do not necessarily represent those of EUMETSAT. This message and any attachments are intended for the sole use of the addressee(s) and may contain confidential and privileged information. Any unauthorised use, disclosure, dissemination or distribution (in whole or in part) of its contents is not permitted. If you received this message in error, please notify the sender and delete it from your system.
Received on Thu Jun 11 2015 - 10:00:12 BST