Jonathan, I think Nan has a very good point. I think we can add verbiage to the definition of gregorian that will be sufficient.
I think, too, that gregorian_nls shouldn't be taken to imply that UTC was ever used. In fact, if we keep gregorian, I think that there is no need for gregorian_nls. My suggestion for a working definition for gregorian_nls was "Reference timestamp expressed in Gregorian calendar with generic time system having 86400 seconds per day based at longitude 0 degrees. There is no exact conversion available between this and other calendars." Grace and peace, Jim [image: 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] o: +1 828 271 4900 *Connect with us on Facebook for climate <http://www.facebook.com/NOAANCEIclimate> and ocean and geophysics <http://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at @NOAANCEIclimate <http://www.twitter.com/NOAANCEIclimate>and @NOAANCEIocngeo <http://www.twitter.com/NOAANCEIocngeo>.* On Fri, Jun 26, 2015 at 1:10 PM, Jonathan Gregory <[email protected] > wrote: > Dear Nan > > Thanks for your comment and for keeping up with the discussion. So do you > think > we should distinguish these cases: > > gregorian_nls. The timestamps are the real-world UTC but encoded without > leap > seconds (all days of 86400 s), so not quite accurate for elapsed times, but > decoding the time coordinates will give exactly the timestamps the data- > producer intended. > > gregorian. The timestamps might be GPS or UTC, and they might be encoded > with > or without leap seconds, but this information is not specified, because the > data producer doesn't think that such precision is needed. In that case the > decoded timestamps will not necessarily be accurately what the > data-producer > intended, because it's not recorded how the encoding was done. > > I think it would be good not to have a default. At present sec 4.4.1 > recommends > that the calendar is specified, but I see that we haven't included that in > the > conformance doc. We should have done so, and the CF checker should produce > a > warning if the calendar attribute is absent on a time coordinate variable. > > Best wishes > > Jonathan > > > ----- Forwarded message from Nan Galbraith <[email protected]> ----- > > > Date: Fri, 26 Jun 2015 10:36:44 -0400 > > From: Nan Galbraith <[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.6; rv:31.0) > > Gecko/20100101 Thunderbird/31.7.0 > > > > Hi all - > > >I am sure that everyone else is quite tired of listening to us by > > >now, if they still are. :-) > > I've been following this thread, but have not spoken up before because > > the tiny offsets in the time coordinate that are being discussed are so > > far below the noise level in my time word as to be meaningless. And, > > something tells me, I'm not the only one. > > > > Most in situ data is measured at different points, or for different > > durations, > > within a nominal sample window; in my case, that window is usually > between > > a minute and an hour. Instrument clocks drift for minutes, every > > year they're > > in the field. So, for a lot of in situ data, leap seconds are truly > > beside the point. > > > > Maybe this is what you mean by 'playing fast and loose with time'? If > > that's what your instruments do, I'm thinking your data shouldn't try to > > nail things down too much more tightly. > > > > I understand that for some data sets, an accurate description of the > > time is > > critical - but when you implement a standard that accommodates that need, > > you shouldn't make it too much more complicated for those with other > kinds > > of data sets. > > > > So my request is to keep it simple for the many CF users who will > > not be aware > > that the calendar they're using (by default, or explicitly) is > > different from what > > a GPS-enabled device would provide. Please keep gregorian as an option, > and > > as the default calendar. If a user goes with this, instead of the > > more specific > > terms you're proposing, that tells you what you need to know about > > their time > > word. > > > > I do use the calendar attribute in my data. Maybe it's not 'accurate in > the > > real world' - but neither is the time word in a lot of my data. It's > > a good fit. > > > > Cheers - Nan > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
