Jonathan,
I think Nan has a very good point. I think we can add verbiage to the
definition of gregorian that will be sufficient.
I think, too, that gregorian_nls shouldn't be taken to imply that UTC was
ever used. In fact, if we keep gregorian, I think that there is no need for
gregorian_nls. My suggestion for a working definition for gregorian_nls was
"Reference timestamp expressed in Gregorian calendar with generic time
system having 86400 seconds per day based at longitude 0 degrees. There is
no exact conversion available between this and other calendars."
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: jbiard at cicsnc.org
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 _at_NOAANCEIclimate
<
http://www.twitter.com/NOAANCEIclimate>and _at_NOAANCEIocngeo
<
http://www.twitter.com/NOAANCEIocngeo>.*
On Fri, Jun 26, 2015 at 1:10 PM, Jonathan Gregory <j.m.gregory at reading.ac.uk
> wrote:
> 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
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150626/a683bd8f/attachment-0001.html>
Received on Fri Jun 26 2015 - 11:40:16 BST
