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
