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
On 6/25/15 3:11 PM, Jonathan Gregory 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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150626/ad504436/attachment.html>
Received on Fri Jun 26 2015 - 08:36:44 BST
