Jonathan, Sounds like we are in agreement! Thanks for your patience with me. I defer on the question of forms of deprecation, abolishment, etc to you and others in the community.
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 Thu, Jun 25, 2015 at 3:11 PM, Jonathan Gregory <[email protected] > wrote: > Dear Jim > > > Man, are we ever getting close now! > I am sure that everyone else is quite tired of listening to us by now, if > they > still are. :-) > > > The gregorian_utc_lse case was my way of distinguishing the entirely > > approximate case of gregorian_nls from the case where you have a UTC > > reference timestamp that is firmly embedded in the real world, had input > > timestamps that were also UTC and firmly embedded in the real world, but > > used a mismatched algorithm when you created your elapsed times. (The > > algorithm was likely the POSIX/nls algorithm, but it could also have been > > the GPS algorithm, for example.) > ... > > This was my stab at an explicit declaration. As I mentioned, this case > > really isn't terribly far off from the gregorian_nls case. A > misapplication > > of encoding algorithm has rendered the result (possibly) approximate, so > > with appropriate wording in the definition the gregorian_nls calendar > would > > likely be enough. > > OK, I see. The cases are materially the same, aren't they; the difference > is > whether it's accidental or on purpose. If we can devise wording which > covers > both cases at once, and call it gregorian_nls (which is simpler), I think > that > would be preferable. > > You suggested we might permit "gregorian" as a synonym for this, for > backward > compatibility. If we do so, I think we should deprecate "gregorian", so > the CF > checker gives a warning. Much earlier in this discussion, I proposed that > we > should disallow any default or "standard". These would be > backward-incompatible > changes, which I usually oppose! Maybe that is too severe, and we should > retain > those possibilities as well as synonyms for gregorian_nls, but also > deprecated. > But it would seem odd to have as default a calendar which isn't accurately > the > real world and is not standard. Therefore I'm still inclined towards > abolishing > them. What do you think? > > Best wishes > > Jonathan >
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
