Jonathan,
On 7/13/15 10:45 AM, Jonathan Gregory wrote:
Dear Jim
I look at your second case and consider that this looks a whole lot
like the plain gregorian calendar case. While inputs may have been
timestamped with UTC times, the model output definitely isn't UTC,
and I don't see any justification for the level of precision implied
by gregorian_utc_nls. (Note that if you know you have elapsed time
encoded from UTC without considering leap seconds, you can actually
precisely handle it. It's just that there are potential
discontinuities and/or offsets encoded into the elapsed times.) As a
result, I'd say that your second case should be labeled with
gregorian, not gregorian_nls.
I don't agree with that, because gregorian is *imprecise*. It is deliberately
not defined whether it is GPS or UTC or whether there are leap seconds in the
encoding. This is reasonable for applications which aren't affected by this
level of precision, or the precise information is not available.
However, models running to simulate the real world (without leap seconds)
are *precise*. They do run with second precision, and there is a need to
decode their time coordinates to timestamps which are exactly right. It would
be unsatisfactory not to be able to do this, or to get timestamps which were
wrong by odd numbers of seconds. Hence this is a different case from gregorian.
I agree that you can exactly decode gregorian_utc_nls to get the accurate
timestamps, and that the inaccuracy is in the elapsed time. But that is a
different case too. For models running with gregorian_nls, the elapsed time
is correct (in model world) as well as the decoded timestamps.
Therefore I think gregorian, gregorian_utc_nls and gregorian_nls are different
and necessary use-cases, but it's the latter two which are most similar. They
are so similar that it would be hard to choose the right one reliably, so I
would rather not make the distinction. gregorian_nls cannot properly be called
UTC, because it isn't, but gregorian_utc_nls could be called gregorian_nls,
because _nls won't be needed for any real-world times apart from UTC. I'm sorry
not to have thought this through last week.
Hmmmm... 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?
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. (And I'm not trying to denigrate models in
any way when I say that.)
I'd like to hear your thoughts about this while I continue to ponder this.
Best wishes
Jonathan
Grace and peace,
Jim
On 7/13/15 6:18 AM, Jonathan Gregory wrote:
Dear Jim and Karl
Thanks for your emails.
To Jim, I think I spoke too soon! I do agree that it's better to be precise,
but I'm concerned on reflection that there are two uses of real-world time
encoded as if there were no leap seconds in the real world:
* Observational data or models run with observational input, where the data
is timestamped in UTC, but encoded as coordinates without leap seconds. This
is what we agreed to call gregorian_utc_nls. In this case we pretend that the
real world has a constant day-length and no leap seconds.
* Models run to resemble the real world, with the real-world calendar and the
intention to compare actual weather or climate with model output, but without
leap seconds. CMIP5 historical and AMIP experiments are in this category, for
which some models use the real-world calendar (but no leap seconds), and some
of the input (for instance SSTs and atmospheric composition) refers to the
real-world calendar. However it is model data, and the model definitely does
not have leap seconds, so cannot truly be UTC at all. It actually is running
with a constant day-length. Thus we can't rightly call this gregorian_utc_nls.
It would be more accurate to call it gregorian_nls (not UTC, not GPS).
However the distinction between gregorian_utc_nls and gregorian_nls is very
subtle. I can barely see it myself, even when writing about it! I expect it
would not reliably be made by data-producers. Therefore I'd like to revert to
gregorian_nls for both cases. I think this only applies to UTC really. GPS
does not have leap seconds anyway, so a special no-leap-second encoding would
only be needed if you put a reference time for GPS before the GPS epoch. Maybe
we should disallow that, to avoid this ambiguity.
Therefore, with apologies, I have to ask the opposite question of whether you
could live with gregorian_nls to mean encoded UTC when it's truly real-world
data. I don't think it's satisfactory to call it just "gregorian" because we
have also recognised the need for a deliberately imprecise situation, when it's
not known if it's GPS or UTC or how encoded. gregorian_nls is precisely 86400-
second days, encoded as such, by intention.
Karl, do you have any comments about this?
Karl, I agree with your analysis. Jim and I also discussed ways of changing
the calendar, and we decided it wasn't essential to the definitions as such
to say how you could do it. Another possibility for changing from UTC to GPS
or v-v is to alter the reference time and its calendar so it refers to the
same instant in the real world. Then you don't need to alter the encoded time
coords. For changing between real-world and model calendars, I would argue that
they are only related via timestamps in principle (that is, January is the same
in both sorts of calendar only because it's regarded as January and comparable
for that reason), and the simplest way to convert is to decode the coords to
timestamps in the old calendar and reencode in the new calendar.
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
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Grace and peace,
Jim
--
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
