Karl,
That pretty much sums it up!
It's good to keep straight that the addition of a leap second or a leap
day does not alter a simple elapsed time count of seconds or days, such
as that kept by an atomic clock. It is a convention for adjusting the
clock or calendar display so that it conforms to the natural rotational
or orbital motion of the Earth. What you've said isn't in disagreement,
but folks can get confused about that (like with "gaining an hour" when
we go from Daylight Savings Time to Standard Time).
I see a motivation for gregorian_utc_nls for people that have an
existing dataset and would like to better document what was done with
time without modifying the actual data by altering the calendar
attribute. The other practical use case is people that are trying to
create time variables from UTC time stamps using a standard computer
system without the software needed to do proper leap second handling.
Most of them probably don't need the accuracy and precision we are
talking about, but I think this case probably covers a large section of
our observational user population. Other than that, I'm good with your
proposal.
Grace and peace,
Jim
On 7/13/15 4:36 PM, Karl Taylor wrote:
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
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: [email protected] <mailto:[email protected]>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
