⇐ ⇒

[CF-metadata] How to define time coordinate in GPS?

From: Jonathan Gregory <j.m.gregory>
Date: Thu, 25 Jun 2015 21:11:58 +0200

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
Received on Thu Jun 25 2015 - 13:11:58 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒