Dear Jim and Jonathan,
Having tried to learn about UTC and GPS time systems, I think we'll need
to find a way to explain to CF users in a simple way what calendar they
should use and when.
The GPS system relies on "24-hour (exactly 86400 sec) wall-clock"
without leap seconds added, which means the phase of the solar day
(defined by the Sun's position in the sky) slowly gets out of sync with
the clock. The phase shifts primarily because on average the earth
takes about 86400.002 seconds to complete a rotation (relative to the
position of the sun), which implies a drift of 1 second per 2 years on
average, but with some variation around this drift rate because the
earth's rotation rate is not constant. [So we shouldn't say "GPS
assumes an 86400 sec *day*"; it assumes a 86400 sec *clock*, which
implies that for our earth, the phase of the day gets out of sync with
the clock.]
Under the UTC system, leap seconds are added (or removed) when necessary
(about every 2 years) to keep the clock in sync with sun. Under the UTC
system the sun rises and sets at a UTC time which (to within about a
second) depends only on one's location on earth and the orbital
longitude (not the year). This is not the case under the GPS system
where there is a slow, somewhat uneven, drift in these times.
For models, we have a different case from either of these: the earth
rotates once in exactly 86400 seconds (not 86400.002 sec), and so a
GPS-like wall clock (without leap seconds) remains in sync with the
sun's position in the sky. This means that our model clock behaves like
a UTC clock (by staying in phase), but like a GPS clock in that there
are no leap seconds.
If we had discussed this at the beginning of CF, we could have come up
with a simple system:
"gregorian" representing the model's approximation of nature (by
rounding the length of the mean solar day from 86400.002 to 86400) and
the use of a clock without a need for leap seconds. [This is in
addition to assuming days follow the gregorian calendar and the rules of
when leap years occur.] By construction, this calendar would only apply
to models.
"gregorian_utc" used for earth measurements to specify a reference time
expressed according to the UTC time-system (and elapsed time correctly
recorded).
"gregorian_gps" used for earth measurements to specify a reference time
expressed according to the GPS time-system (and elapsed time correctly
recorded).
In trying to retrofit CF, there are, however, two problems with the
above system:
1) "gregorian" has in the past, at least, been used for earth
measurements (where the day is 86400.002 seconds long)
2) In the future some folks may want to specify (incorrectly or
imprecisely at least) a reference time expressed according to the UTC
time-system but with wall-clock times converted to elapsed time omitting
leap seconds.
As I understand it, our proposed solution is to
A) define "gregorian" to be a time-system without leap seconds, with
reference times (part of the units) and elapsed time being somewhat
imprecise, so that one can not determine the phase of the diurnal cycle
to within better than about 16 seconds (of time) and when comparing two
different datasets, time-coordinates that are identical may in fact
represent times differing by as much as 16 seconds. This definition
makes gregorian backward compatible in our conventions.
B) define "gregorian_utc_nls for a case where the reference time is
expressed correctly according to the UTC time-system, *but* elapsed time
is given following an algorithm that omits leap seconds (and thus
elapsed time may be off by up to 16 seconds). This would be used only
for observational data.
C) define "gregorian_nls" for a case where the solar day is exactly
86400 seconds long. This would only be used for models (replacing
"gregorian" which was used in the past), but which would exclude the
imprecise specification we now propose for "gregorian").
Personally, I wouldn't bother with C), at least not now, because with
models, I think we can count on the solar day being 86400 seconds long.
Under my proposal, "gregorian" without a suffix would imply:
1) if model data, the solar day should be assumed to be 86400 seconds long.
2) If observational data, one should not rely on the time coordinate
being accurate to within better than 16 seconds.
I also wouldn't bother with B). If a provider of observational data
wants to precisely specify time, then they should follow either
"gregorian_nls" or "gregorian_utc". Otherwise they should specify
"gregorian" which means their coordinate values may be off by as much as
16 seconds.
Best regards,
Karl
On 7/13/15 9:45 AM, Jonathan Gregory wrote:
> Dear Jim
>
>> If the input times were GPS times, would you - as a modeler
>> - feel the need to convert those times to UTC times before using
>> them in your model?
> No.
>
>> I've never dealt with weather or climate models, but it seems to me
>> that while models are precise regarding time, they may not be
>> accurate - in that having your inputs off by 15 seconds won't make a
>> material difference in your outputs.
> That is quite true. In that sense it is inaccurate, like the gregorian case.
> However, unlike the gregorian case, it is precise once the data is transplanted
> to the model world. In the output, I wish to encode a time coordinate of
> exactly midnight on 2015-7-13, for instance, and I want my calendar attribute
> to describe this as being in the no-leap-second world, precisely. This means
> the data-user will decode my time coordinate precisely correctly. It would
> be surprising or confusing if the data-user decoded with leap seconds, getting
> a timestamp a quarter of a minute wrong, and "gregorian" would permit that
> option. Also, the user can depend on every day having 86400 seconds, if the
> coords are used as elapsed times.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Mon Jul 13 2015 - 14:36:51 BST
