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 <[email protected]> > To: [email protected] > 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 > >[email protected] > >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: [email protected] <mailto:[email protected]> > 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 @NOAANCEIclimate > <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo > <https://twitter.com/NOAANCEIocngeo>. / > > > _______________________________________________ > CF-metadata mailing list > [email protected] > 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: [email protected] _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
