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

From: Jonathan Gregory <j.m.gregory>
Date: Thu, 25 Jun 2015 08:57:50 +0200

Dear Jim

Thank you for your detailed argument. I suspect we almost agree now, though I
hesitate because I haven't quite followed your reasoning in a couple of places,
and it may turn out from this that I have misunderstood something.

If the calendar for the reference timestamp is GPS, the input timestamp is
UTC, and the encoding algorithm is UTC, you say there is no error. Wouldn't
the UTC algorithm assume that the reference timestamp is UTC? In that case
there could be an error. Perhaps you think that in this case the reference
timestamp would first be converted to UTC, before the encoding? If that were
done, there would be no error.

> The GPS timestamp to elapsed time encoding algorithm is (apart from epoch date
> & time) the same as the POSIX algorithm assuming you haven't enabled POSIX leap
> second sensitivity (which is possible, but almost no one does it). It handles
> Gregorian leap days, but not leap seconds.

Yes. This is the same as the NLS algorithm. The reference time is not part of
the algorithm. The function of the algorithm is to compute the elapsed time
between the ref timestamp and the input timestamp.

> The only thing that affects the contents of the time variable is whether or
> not the encoding algorithm matched the input timestamp calendar

Yes, I think so, except that the encoding algorithm assumes that the ref
timestamp is in the same calendar as the input timestamps i.e. the calendar
of the algorithm.

+-----------------------------------------------------------------------------+
| Calendar | Definition |
|-------------------+---------------------------------------------------------|
| gregorian_utc | Reference timestamp expressed in Gregorian calendar |
| | with UTC time system. Elapsed times are free of leap |
| | second errors. |
|-------------------+---------------------------------------------------------|
| gregorian_utc_lse | gregorian_utc, but elapsed times are not necessarily |
| | free of leap second errors. There is no exact |
| | conversion between this and other calendars. |
|-------------------+---------------------------------------------------------|
| gregorian_gps | Reference timestamp expressed in Gregorian calendar |
| | with GPS time system. Elapsed times are free of leap |
| | second errors. |
|-------------------+---------------------------------------------------------|
| gregorian_nls | Reference timestamp expressed in Gregorian calendar |
| | with generic time system having 86400 seconds per day |
| | based at longitude 0 degrees. There is no exact |
| | conversion available between this and other calendars. |
+-----------------------------------------------------------------------------+

gregorian_utc and gregorian_gps are fine.

I am not sure of the distinction between gregorian_utc_lse and gregorian_nls,
unless it's a degree of vagueness. In practice, input timestamps
from the real world are usually are UTC. I think if you were using GPS or TAI
time instead, you would be well aware of it. The case to be described is the
one where the reference and input timestamps are actually UTC, but they are
interpreted as belonging to a calendar which has no leap seconds, and hence
encoded with the NLS calendar. As you say, this calendar can't be converted
exactly to the real world, and the time coordinates may have small differences
from real-world elapsed times. It is useful to recognise, as you do, that
gregorian_nls is not a real-world calendar, but it is a near enough approx
for many purposes.

> If we changed the definition of the 'gregorian' calendar to be the same as the
> 'gregorian_nls' calendar above and included some text warning people that
> resolutions of < 1 minute are suspect, then we'd have a backward compatibility
> path.

Yes, I agree.

> In fact, we could just use 'gregorian' to cover the 'gregorian_utc_lse'
> case.

Please could you help me to understand what this case is?

Best wishes

Jonathan
Received on Thu Jun 25 2015 - 00:57:50 BST