Jonathan,
I appreciate your willingness to continue this attempt to find a meeting
of the minds about all of this. I hope you will forgive me if I am not
always completely clear in my attempts to express myself or fail to
understand you.
And now, back to the "struggle".
As a data consumer, all I have to do is convert the reference time from
the stated calendar to my desired calender, then use that as the basis
for producing timestamps from the elapsed times in the variable (using
the correct set of time functions, of course). Expressing the elapsed
times as timestamps in one calendar and then converting those timestamps
to another is another way that you could do it, but one which adds
unneeded steps. I don't see any reason to assume that data consumers
would work in one particular way.
The reference timestamp in the units attribute is what anchors the
elapsed time values into history. That's all that is needed. If you
modify a time variable by giving the calendar attribute a new value and
changing the timestamp in the units attribute from the original calendar
to the new calendar, the contents of the altered time variable will
still refer to the same points in history. The elapsed time values
stored in the variable are unaffected. The purpose of the calendar
attribute is to tell you how to interpret the reference epoch timestamp,
not to tell you how to interpret the elapsed time values.
I think that CF conventions sections about the calendar attribute should
say something along the lines of:
4.4.1 Calendar
In order to know what point in history has been measured by a given
base date, base time, and time increment, one must know what
calendar was used for the base date and time. The calendar attribute
defines the particular date and time system that was used to express
the reference time string found in the units attribute, and is
assigned to the time coordinate variable. The values currently
defined for calendar are:
...
Grace and peace,
Jim
On 6/10/15 11:18 AM, Jonathan Gregory wrote:
> Dear Jim
>
> I agree about your kg example. Units conversion alone is something the user is
> free to do. I also agree that nothing prevents a user from converting the xy
> coords to another system. The data-producer's intention is not altered by
> that, and so long as the coordinates have been properly described it will be
> possible for the user to do this. Time is a similar case. If it makes sense to
> convert between systems (between real-world Gregorian or Julian, or real-world
> UTC and GPS) then it's fine to do so. I think the user will do this by first
> decoding the time coordinate into the timestamps in the calendar which the
> data-producer recorded, and then converting them to another set of timestamps
> in the chosen calendar.
>
> So I agree with your statement:
>
>> it is crucial that I
>> know where the elapsed time values stored in my time variable are
>> anchored in history, and that is what we should be trying to make
>> clear with the units and calendar attributes (and any other
>> time-related attributes that might arise).
> I believe that's what we would be doing still in my proposals. The encoded
> values are elapsed time values, so they can be manipulated as such, and they
> can be anchored in history by decoding them into timestamps (probably not
> string-valued timestamps, but numerical components of time), using the stated
> calendar. The components of time are, in most cases, the original information
> which the data-producer had. This is why I think it's correct to view our
> treatment of time coordinates as an encoding.
>
> Therefore I find I'm still not clear why you disagree with my statement:
>
>> Clarify that in the CF convention the choice of "calendar" implies the
>> particular set of rules that is used to convert between date-times (YYYY-MM-DD
>> hh:mm:ss i.e. sets of six numbers) and time coordinates in units of elapsed
>> time since a reference time.
> Best wishes
>
> Jonathan
>
> ----- Forwarded message from Jim Biard <jbiard at cicsnc.org> -----
>
>> Date: Wed, 10 Jun 2015 09:51:21 -0400
>> From: Jim Biard <jbiard at cicsnc.org>
>> To: cf-metadata at cgd.ucar.edu
>> Subject: Re: [CF-metadata] How to define time coordinate in GPS?
>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
>> Gecko/20100101 Thunderbird/31.7.0
>>
>> Jonathan,
>>
>> I didn't see your initial statement that you reference as enforcing
>> anything on data consumers, or I would have raised this earlier.
>>
>> Let's think about this in a simpler context. If I, as a data
>> producer, store values in a data variable in units of kilograms and
>> designate it as such with the units attribute, that doesn't mean
>> every data consumer should feel like they must display the values as
>> kilograms. They are free to select the units they prefer and, as
>> long as they do the conversion correctly, that is completely fine.
>>
>> In a more complex and somewhat analogous case, if I as a data
>> producer store my geographic coordinates in latitudes and
>> longitudes, and properly designate the units and the reference datum
>> that I used, data consumers can display my data using those
>> latitudes and longitudes, or they can display my data using a
>> projected coordinate system where they have converted my latitudes
>> and longitudes into X and Y values, or whatever else they choose
>> (and I hope that whatever else they might do is valid!). What I must
>> do as a data producer is accurately identify the geographic
>> Coordinate Reference System that is the basis for my geographic
>> coordinate values (and then make sure that my coordinate values are
>> correct if I started in some different CRS).
>>
>> A properly formed time variable needs to have contents that are
>> metric (by that I mean that you can do differencing math with the
>> values), and if it contains real-world time observations it needs to
>> be anchored to a recognizable point in history. The system we have
>> in place using elapsed time values with a reference epoch does just
>> that.
>>
>> The decision about how to represent the time values as timestamps
>> for display purposes should be left up to the data consumer. You may
>> have used a reference epoch expressed using the Proleptic Gregorian
>> calendar, but if I would rather express timestamps on my plots using
>> the Julian calendar, that's my business. Perhaps the discipline I am
>> working in has a convention of using Modified Julian Days, so I am
>> going to convert everything to days since 1858-11-17 00:00:00.
>>
>> Whatever my choice of output form for times, it is crucial that I
>> know where the elapsed time values stored in my time variable are
>> anchored in history, and that is what we should be trying to make
>> clear with the units and calendar attributes (and any other
>> time-related attributes that might arise).
>>
>> Grace and peace,
>>
>> Jim
>>
>> On 6/9/15 1:21 PM, Jonathan Gregory wrote:
>>> Dear Jim
>>>
>>> You wrote
>>>> 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.
>>> You are right to point to this as a point of disagreement. I thought we had
>>> discussed this earlier e.g. in
>>> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2015/058224.html
>>> I wrote
>>>> Clarify that in the CF convention the choice of "calendar" implies the
>>>> particular set of rules that is used to convert between date-times (YYYY-MM-DD
>>>> hh:mm:ss i.e. sets of six numbers) and time coordinates in units of elapsed
>>>> time since a reference time.
>>> and I believe that this arose from an earlier discussion about this being a
>>> CF-specific use of the term "calendar". Maybe I have misunderstood you now.
>>>
>>> I think the data producer is the person who decides what the data means. If
>>> the producer has Julian calendar timestamps and encodes with Julian rules
>>> as a time coordinate variable, the data-user is wrong to decode them with
>>> any other rules into timestamps or interpret them as being in any other
>>> calendar. Why would that be a useful thing to do? I agree with your earlier
>>> posting and email that there is a range of timestamps which refer to the same
>>> points in time in the Gregorian and Julian calendars (long ago, before they
>>> drifted apart) so for that range of dates it would not matter if the data-
>>> user changed the calendar, since they're indistinguishable. But that is a
>>> special case. If you come up to present, a given time-stamp refers to a
>>> different instance in time in the Gregorian and Julian calendars, just like
>>> it does between UTC and GPS calendars. For model calendars, it would be
>>> nonsense for time coordinates encoded in the 360-day calendar to be decoded
>>> in the proleptic Gregorian calendar, for example.
>>>
>>> Perhaps we view time coordinates in different ways? I think the timestamps
>>> are the primary information, and the time coordinates are an encoded version.
>>> We do it like that for efficiency of storage, and convenience and robustness
>>> of processing, since string-valued timestamps are relatively awkward. It has
>>> also the great advantage that the encoded time coordinate is also an elapsed
>>> time variable, so it can be used to check monotonicity and for calculations.
>>> This is a common need, since time is a continuous coordinate.
>>>
>>> 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
--
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/20150610/719dba9c/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/20150610/719dba9c/attachment-0001.png>
Received on Wed Jun 10 2015 - 10:38:21 BST
