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

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 15 Jul 2015 09:34:30 +0100

PS. First, to repeat myself:

So my conclusion (at present - but I suspect I haven't understood something
you have said) is that gregorian is fine and sufficient (with the addition of
gregorian_utc and gregorian_gps for the well-defined real-world systems) if
we define it to mean that 86400-seconds are assumed to be used for conversion
from clock time to elapsed time and elapsed time to clock time, that it is not
defined whether the reference time and clock times are GPS and UTC, and that
the elapsed times may not be exactly correct for the real world (due to the
neglect of leap seconds).

I also said, "This is then the same as gregorian_utc_nls, so we would not need
that either, which was your final conclusion in your previous post." Actually
it's not quite the same as gregorian_utc_nls, which asserts that clock times,
if real-world, are UTC. Otherwise it's the same. If my conclusion above is
correct, then I don't mind whether we introduce gregorian_utc_nls or not. No-
one has definitely asked for it, as far as I remember; we discussed it because
of anticipating the need, I believe. We could therefore follow the usual CF
principle of omitting it until it's asked for.

Cheers

Jonathan

----- Forwarded message from Jonathan Gregory <j.m.gregory at reading.ac.uk-----

Date: Wed, 15 Jul 2015 08:01:04 +0100
From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] How to define time coordinate in GPS?
User-Agent: Mutt/1.5.21 (2010-09-15)

Dear Karl

I think the meaning of "gregorian" up to CF 1.6 is actually not clear, because
we had not thought about these distinctions earlier. If we change the calendar
definitions, it does not affect the interpretation of any existing data written
with previous versions. However I agree that it would be inconvenient for data-
users if they had to process "gregorian" times differently according to the
setting of the Conventions version.

I thought that the current proposal was that gregorian would be vague in
future, like you wrote in your second option:

1) might or might not account for leap seconds, 2) might or might not assume
the length of the solar day is exactly 86400 seconds long, and 3) might express
the reference time according to either UTC or GPS

and that is exactly the reason why, after agreeing with Jim last week, I
changed my mind to argue that we needed gregorian_nls for model data, to
preserve the exactness for times which really are always 86400-second days.
You agree we would need gregorian_nls in that case. I agree that it means that
models would use gregorian_nls in future, not gregorian.

However in your first option you don't think this is necessary:

Under the "gregorian" calendar the length of the solar day can be assumed to be
exactly 86400 seconds long (i.e., there are no leap seconds). This means that
for models where this assumption almost invariably is valid, conversion from
elapsed time to clock time is straight-forward and exact, whereas for
observations, conversion to clock time may introduce errors as large as 16
seconds because it is unknown whether the UTC or GPS time system has been used
in specifying the reference times (appearing in the time units attribute), and
it is also unknown whether leap seconds have been properly accounted for in
converting UTC clock times to elapsed time.

I'm sorry, but I can't see what is the difference. In both cases you say it
is unknown whether leap seconds have been included in converting from clock
time to elapsed time. Is the crucial difference about the length of the day?
Does "assume the solar day to be exactly 86400 seconds" mean "assume all days
are 86400 seconds in converting elapsed time to clock time"?

If that's what you mean, I think your first and preferred option is fine, and
then I agree we do not need gregorian_nls. To spell it out, I think this is
acceptable if "gregorian" means that you will recover the clock times (time-
stamps) exactly by using an algorithm that assumes constant 86400-second days
(i.e. with no leap seconds). If these clock times refer to the real world, it
is undefined whether the reference time is GPS or UTC, and consequently it is
undefined whether the decoded clock times are GPS or UTC.

But my statement "you will recover the clock times (time-stamps) exactly by
using an algorithm that assumes constant 86400-second days" is inconsistent
with your statement "conversion to clock time may introduce errors ... because
it is unknown whether ... leap seconds have been properly accounted for in
converting UTC clock times to elapsed time". According to my statement,
gregorian means that leap seconds were ignored when converting clock times to
elapsed times i.e. 86400-second days were used. If that's not the case, you
can't decode accurately. Thus the elapsed times may not be quite right for the
real world. This is then the same as gregorian_utc_nls, so we would not need
that either, which was your final conclusion in your previous post.

So my conclusion (at present - but I suspect I haven't understood something
you have said) is that gregorian is fine and sufficient (with the addition of
gregorian_utc and gregorian_gps for the well-defined real-world systems) if
we define it to mean that 86400-seconds are assumed to be used for conversion
from clock time to elapsed time and elapsed time to clock time, that it is not
defined whether the reference time and clock times are GPS and UTC, and that
the elapsed times may not be exactly correct for the real world (due to the
neglect of leap seconds).

Best wishes

Jonathan
Received on Wed Jul 15 2015 - 02:34:30 BST