Jonathan,
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.
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
> 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/831dcc72/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/831dcc72/attachment-0001.png>
Received on Mon Jul 13 2015 - 07:50:15 BST
