Jonathan,
I've got to disagree with you about your second and third responses
below. The calendar only specifies how the reference date and time are
to be interpreted. It says nothing about either the time variable values
or the decoding that should be used to turn those elapsed time values
into dates and times. That choice is entirely up to the data consumer.
If a data producer started with a set of Julian calendar dates and
created a time variable, and a data user prefers to use Proleptic
Gregorian dates, there is no problem. One is not more correct than the
other.
Grace and peace,
Jim
On 6/3/15 10:47 AM, Jonathan Gregory wrote:
> Dear Chris
>
>> While not happy, would you agree to introduce gregorian_utc, gregorian_gps,
>> gregorian_nls, define gregorian = gregorian_nls and deprecate it?
>>
>> seems reasonable to me.
> Good.
>
>>> I think we
>>> should omit gregorian_tai (although it's been instructive to discuss it)
>>> since it's not been asked for yet.
>> fine with me -- I don't need it :-) -- though I thought that was the start
>> of this entire discussion.
> The title of the thread is GPS. But maybe it was TAI. Please could anyone who
> needs TAI speak up!
>
>>>>> so the Calendar is ONLY for defining the reference
>>>>> timestamp in the units.
>>> I don't agree still with this. The calendar specifies the time system for
>>> the reference time-stamp and the decoded time-coordinates,
>> I'm confused -- in the file, there are ONLY encoded time on the time
>> coordinates. How it gets decoded is entirely up to the data user -- they
>> can put it any calendar they want. I suppose your point is that the data
>> provider is specifying how the time coordinate is intended to be used --
>> which is fine. I can't imagine it would cause any problems to think of it
>> that way.
> Yes, that's what I meant. If the decoding is done as specified by the method
> implied by the calendar, the timestamps are (a) correct for and (b) should be
> interpreted as being in that calendar. As a result of this discussion I see
> that (a) and (b) are not the same, but they belong together.
>
>>> I have learned,
>>> and it also specifies how the translation is done.
>> by whom? when? my point is that the translation is up to the data user --
>> it's not in the file.
> By identifying the calendar, the data-producer is (a) stating the method
> which was used to encode the time coordinates (b) instructing the data-user to
> use the reverse of that method to decode them into timestamps.
>
> 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/20150603/f44046a1/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/20150603/f44046a1/attachment-0001.png>
Received on Wed Jun 03 2015 - 10:21:06 BST
