Tim,
And, as I see it, CF defines your first case for time, not the alternative.
Jim
On 6/10/15 11:10 AM, Timothy Patterson wrote:
> It seems to me the various choices basically come down as to whether the producer or the user should have the responsibility of converting/interpreting the contents of the time variable.
>
> If time coordinate was seen as equivalent to weight or temperature, then we would have units and a convenient offset time to keep the size of the stored numbers manageable. This would be a simple count of time units (no gaps, leaps, etc.). The producer would be responsible for encoding whatever time/date/calendar they had used locally for their timestamps into these time units for storage in the netCDF file. The user could then either use these units, if convenient, or convert them into whatever timestamp they liked (even something not in the CF like the Mayan calendar!).
>
> Alternatively, the responsibility is placed on the user, by having a time unit into which a producer can dump their timestamps and add a set of attributes that explain to the end user how their particular timestamps need to be interpreted and processed. It's then up to the end-user to read the timestamps correctly and convert to a continuous time coordinate if required.
>
> In the first case, a time variable is unambiguous and equivalent to other measurements like weight and temperature. You can use it as a coordinate straight from the box. In the second case, the time variable may contain one of a variety of different encodings and will often require some assembly by the user before use.
>
> Regards,
>
> Tim
>
>
>
> -----Original Message-----
> From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of David Hassell
> Sent: Wednesday, June 10, 2015 4:14 PM
> To: Jim Biard
> Cc: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] How to define time coordinate in GPS?
>
> Hello Jim,
>
> I'm not entirely convinced by this argument. Here is a counter example that I have in mind:
>
> A conversion from kilograms to carats does not alter anything, fundamentally, in the data values. However, a change of calendar by the user could, for example, place a value in a different year than intended by the producer, in which case annual averages computed by the producer and the user would be different.
>
> What do you think?
>
> All the best,
>
> David
>
> ---- Original message from Jim Biard (09AM 10 Jun 15)
>
>> 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
>
>
> --
> David Hassell
> National Centre for Atmospheric Science (NCAS) Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB, U.K.
>
> Tel : +44 118 3785613
> E-mail: d.c.hassell at reading.ac.uk
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> Any email message from EUMETSAT is sent in good faith but shall neither be binding nor construed as constituting a commitment by EUMETSAT, except where provided for in a written agreement or contract or if explicitly stated in the email. Please note that any views or opinions presented in this email are solely those of the sender and do not necessarily represent those of EUMETSAT. This message and any attachments are intended for the sole use of the addressee(s) and may contain confidential and privileged information. Any unauthorised use, disclosure, dissemination or distribution (in whole or in part) of its contents is not permitted. If you received this message in error, please notify the sender and delete it from your system.
> _______________________________________________
> 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/2fa58ea5/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/2fa58ea5/attachment-0001.png>
Received on Wed Jun 10 2015 - 09:22:43 BST
