Karl,
Jonathan and I spent some time going over what exactly the calendar
attribute implies and indicates. I rest firmly on the position that
(assuming the elapsed times are properly produced so that there are no
discontinuities or offsets) the calendar named in the calendar attribute
only speaks to the interpretation of the reference epoch described in
the units attribute. Jonathan tends towards a view that the calendar
implies something about the usage of the data as well. I was just saying
that the way that Jonathan wrote his second bullet point made valid
statements without causing me any heartburn. ;)
The gregorian_utc_nls calendar diverges from the "only the reference
epoch" case in that it indicates the possibility of discontinuities
and/or offsets in the elapsed times which need to be handled properly on
reading.
Grace and peace,
Jim
On 7/10/15 8:31 PM, Karl Taylor wrote:
> Dear Jonathan and Jim,
>
> I'm o.k. with placing UTC or GPS as part of the calendar attribute
> (rather than in the units). Your arguments in favor of that option
> make sense to me now.
>
> Jim, I think the second bullet (*) point is important and makes sense
> to me. I hope this doesn't mean we're in some disagreement.
>
> In order to compare variables representing measurements taken
> simultaneously, but with one variable stored following the UTC system
> and the other following the GPS system, you could do the following:
>
> 1. Determine the offset between the UTC reference time-stamp and the
> GPS reference time-stamp (note even when the apparent reference times
> are identical, there can be an offset of up to 16 seconds)
> 2. For the UTC variable, subtract the offset (found in step 1) from
> all the time coordinate values. Also change the name of the calendar
> to gregorian_gps. And finally, change the reference time for the time
> units to be the same as the units used for the GPS variable.
>
> Now both variables will have time coordinates that follow the same GPS
> calendar (also with a common reference time). You can then, of
> course, convert the elapsed time to a time-stamp of the form
> 2015-01-01 0:0:0 following the rules of constructing a Gregorian
> calendar (without leap seconds).
>
> If one of the variables has been collected according to UTC, but the
> elapsed time has been stored without accounting for leap seconds
> (i.e., calendar = "gregorian_utc_nl"), then the procedure is more
> complicated:
>
> 1. For each time-coordinate add the number of leap seconds that
> historically have been applied under the UTC system between the
> reference time and the elapsed time. [This converts to gregorian_utc.]
> 2. Follow steps 1 and 2 above to convert to gregorian_gps.
>
> If anyone is really worried about differences in time of a few seconds
> when comparing a model to observations, then things become more
> complicated because the actual length of a model day is exactly 86400
> sec, but the earth's day averages closer to 86500.002 seconds. The
> elapsed time between a sunrise occurring in 1980 and one occurring
> exactly 30 year later will be shorter by 15 seconds in the model. To
> keep the model in sync with the real diurnal cycle, we'll have to
> insert leap seconds into elapsed time. Alternatively, we could throw
> away the leap seconds (and the data associated with those times) in
> the observational dataset and yield a time-series that would stay in
> sync with the model's diurnal cycle.
>
> I would summarize this as:
>
> 1. the length of a real earth day (as gauged by differences in
> elapsed time between the beginning and end of the day) is the same
> whether the elapsed times are recorded using the gregorian_gps or
> gregorian_utc calendars. The UTC system makes sure, however, that
> time-labels stay in sync with the earth's diurnal cycle, whereas the
> GPS system allows the phase of the wall clock to shift relative to the
> earth's diurnal cycle.
>
> 2. the length of a model day (exactly 86500 sec) is a little shorter
> than a real day, and this should be indicated by setting calendar =
> "gregorian" calendar (without suffixes), or one of the other original
> calendar attributes (like "julian" or "noleap").
>
> 3. For observational data, use of calendar="gregorian" indicates that
> the reference time and elapsed time might be wrong by as much as 16
> seconds (but they also might be correct).
>
> Please let me know if my understanding is incorrect (if you can take
> the time to do this).
>
> cheers,
> Karl
>
> On 7/10/15 7:01 AM, Jim Biard wrote:
>> Jonathan,
>>
>> I think I'm just about completely in agreement with you about
>> meanings and such! I think your second bullet (*) point about
>> algorithms is not necessary, but you have worded it in such a way
>> that I'm OK with it.
>>
>> Can you agree to changing gregorian_nls to gregorian_utc_nls? I know
>> it's longer and all, but I think it's better to be precise. This
>> calendar assumes UTC without consideration of leap seconds, and I
>> don't want someone to confuse it with a more generic 'no leap
>> seconds' case. (As a side note, you could have a similar - if
>> unlikely - scenario where someone encoded GPS timestamps using a leap
>> second aware algorithm to get wrong elapsed times. And as long as the
>> inverse of the same algorithm was used to decode to timestamps,
>> correct timestamps would be produced. I guess that calendar would be
>> gregorian_gps_ls. And I'm not suggesting that we add that calendar!)
>>
>> It's also still not to late to go with one or more new attributes to
>> cover the time system instead of making more calendars, but I'm OK
>> with where we are.
>>
>> Grace and peace,
>>
>> Jim
>>
>> On 7/1/15 10:42 AM, Jonathan Gregory wrote:
>>> Dear Karl
>>>
>>> Thanks for your contributions. The points you are raising are similar to those
>>> which Jim and I have been debating for some time, gradually moving towards
>>> mutual understanding! I think the position we had got to is quite economical.
>>> Let me try to relate it to what you suggest.
>>>
>>> Your main suggestion is to allow UTC or GPS to be stated in the time units,
>>> whereas Jim and I have been discussing putting it in the calendar attribute.
>>> The latter is what I prefer because it seems to me that the distinction between
>>> UTC and GPS is quite like the differences among all the model calendars, and
>>> with the real-world calendar. The calendar attribute indicates two things:
>>>
>>> * The calendar (or time system) in which the reference time is stated.
>>>
>>> * The algorithms which should be used to decode the time coordinates into
>>> timestamps in the calendar of the reference time, and to encode timestamps in
>>> that calendar to time coordinates with the given reference time.
>>>
>>> These points distinguish UTC and GPS times, and they similarly distinguish
>>> UTC from 360-day-calendar times, for instance. So it's a more uniform approach
>>> to use the calendar attribute in all cases. Also, parsing the time units att
>>> is less convenient than inspecting the calendar att, which is a single word
>>> with only a small number of possible values.
>>>
>>>> 1) CF not try to accommodate folks using "wrong" software.
>>> The case in point is using software without leap seconds to encode UTC
>>> timestamps. I think it's too harsh to call it "wrong". It pretends that UTC
>>> is something slightly different and other-worldly, and that makes its elapsed
>>> times a bit inaccurate. But it's a perfectly reasonable thing to do. As I
>>> said in a recent email, I expect that many or most climate and NWP models,
>>> when using the "real-world" calendar to deal with real-world weather and
>>> climate (assimilating and comparing with real-world obs), have time coords
>>> which are encoded from UTC timestamps but not using leap seconds i.e. "wrong".
>>> This seems sensible to me since they certainly don't depend on precision to
>>> within a few seconds, and it's easier. So why not? It's not the job of CF to
>>> tell people what to do, and we should accommodate it so long as it's well-
>>> defined and has a use-case.
>>>
>>>> 2) we relax our requirement that udunits be able to handle the time
>>>> coordinate because it won't recognize and interpret "UTC" and "GPS".
>>> udunits can't handle model calendars anyway. We use udunits only to define
>>> the format of the time units, not to depend on it for decoding and encoding.
>>>
>>> There is also a use-case for real-world times where the data-producer is not
>>> precise about whether the ref time is UTC or GPS, or whether the coords were
>>> encoded with leap seconds. It seems that we should distinguish this case from
>>> the precise and deliberate use of 86400-second days for UTC. I think this is
>>> a rather specific case of imprecision, not the same as inaccuracy in coord
>>> values in general (for which we don't have a convention at present - no-one's
>>> asked for one yet), and that it relates specifically to the calendar. So I
>>> still prefer the proposal we've already arrived at for four values of the
>>> calendar att for the real world:
>>>
>>> gregorian: Not specifying whether it's GPS or UTC or how encoded. Elapsed
>>> times and decoded coords are therefore imprecise.
>>>
>>> gregorian_nls: UTC ref time and time coords encoded from UTC timestamps without
>>> leap seconds, which are inaccurate elapsed time, but can be decoded accurately.
>>>
>>> gregorian_utc: UTC ref time, time coords are elapsed time, decoding to UTC
>>> timestamps if UTC algorithm is used.
>>>
>>> gregorian_gps: GPS ref time, time coords are elapsed time, decoding to GPS
>>> timestamps if GPS algorithm is used (which is actually the same algorithm
>>> as for gregorian_nls i.e. 86400-second days).
>>>
>>> Best wishes
>>>
>>> Jonathan
>>> _______________________________________________
>>> 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>. /
>>
>>
>>
>>
>> _______________________________________________
>> 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/ed408adf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150713/ed408adf/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150713/ed408adf/attachment-0003.png>
Received on Mon Jul 13 2015 - 10:01:45 BST
