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

From: Jonathan Gregory <j.m.gregory>
Date: Fri, 26 Jun 2015 19:10:59 +0200

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 <ngalbraith at whoi.edu> -----

> Date: Fri, 26 Jun 2015 10:36:44 -0400
> From: Nan Galbraith <ngalbraith at whoi.edu>
> To: cf-metadata at cgd.ucar.edu
> 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
Received on Fri Jun 26 2015 - 11:10:59 BST