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
>>> 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
>
> ----- End forwarded message -----
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> 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: 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/07595d6c/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/07595d6c/attachment-0001.png>
Received on Mon Jul 13 2015 - 10:15:03 BST
