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
[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
