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
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> 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: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
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 _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150713/4998d54d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150713/4998d54d/attachment-0001.png>
Received on Mon Jul 13 2015 - 15:05:59 BST
