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
Received on Wed Jun 10 2015 - 08:13:56 BST
