Jonathan,
Man, are we ever getting close now!
On Thu, Jun 25, 2015 at 2:57 AM, Jonathan Gregory <j.m.gregory at reading.ac.uk
> wrote:
> Dear Jim
>
> Thank you for your detailed argument. I suspect we almost agree now,
> though I
> hesitate because I haven't quite followed your reasoning in a couple of
> places,
> and it may turn out from this that I have misunderstood something.
>
> If the calendar for the reference timestamp is GPS, the input timestamp is
> UTC, and the encoding algorithm is UTC, you say there is no error. Wouldn't
> the UTC algorithm assume that the reference timestamp is UTC? In that case
> there could be an error. Perhaps you think that in this case the reference
> timestamp would first be converted to UTC, before the encoding? If that
> were
> done, there would be no error.
>
As far as a sequence of events goes, I was pretty much assuming that you
started with all UTC timestamps, then converted the reference to GPS, but
there are a number of ways to get it done correctly.
>
> > The GPS timestamp to elapsed time encoding algorithm is (apart from
> epoch date
> > & time) the same as the POSIX algorithm assuming you haven't enabled
> POSIX leap
> > second sensitivity (which is possible, but almost no one does it). It
> handles
> > Gregorian leap days, but not leap seconds.
>
> Yes. This is the same as the NLS algorithm. The reference time is not part
> of
> the algorithm. The function of the algorithm is to compute the elapsed time
> between the ref timestamp and the input timestamp.
>
> > The only thing that affects the contents of the time variable is whether
> or
> > not the encoding algorithm matched the input timestamp calendar
>
> Yes, I think so, except that the encoding algorithm assumes that the ref
> timestamp is in the same calendar as the input timestamps i.e. the calendar
> of the algorithm.
>
> Yes, whatever the case, you must be cognizant of which timestamp is in
which time system.
>
> +-----------------------------------------------------------------------------+
> | Calendar | Definition
> |
>
> |-------------------+---------------------------------------------------------|
> | gregorian_utc | Reference timestamp expressed in Gregorian calendar
> |
> | | with UTC time system. Elapsed times are free of
> leap |
> | | second errors.
> |
>
> |-------------------+---------------------------------------------------------|
> | gregorian_utc_lse | gregorian_utc, but elapsed times are not
> necessarily |
> | | free of leap second errors. There is no exact
> |
> | | conversion between this and other calendars.
> |
>
> |-------------------+---------------------------------------------------------|
> | gregorian_gps | Reference timestamp expressed in Gregorian calendar
> |
> | | with GPS time system. Elapsed times are free of
> leap |
> | | second errors.
> |
>
> |-------------------+---------------------------------------------------------|
> | gregorian_nls | 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. |
>
> +-----------------------------------------------------------------------------+
>
> gregorian_utc and gregorian_gps are fine.
>
> I am not sure of the distinction between gregorian_utc_lse and
> gregorian_nls,
> unless it's a degree of vagueness. In practice, input timestamps
> from the real world are usually are UTC. I think if you were using GPS or
> TAI
> time instead, you would be well aware of it. The case to be described is
> the
> one where the reference and input timestamps are actually UTC, but they are
> interpreted as belonging to a calendar which has no leap seconds, and hence
> encoded with the NLS calendar. As you say, this calendar can't be converted
> exactly to the real world, and the time coordinates may have small
> differences
> from real-world elapsed times. It is useful to recognise, as you do, that
> gregorian_nls is not a real-world calendar, but it is a near enough approx
> for many purposes.
>
> > If we changed the definition of the 'gregorian' calendar to be the same
> as the
> > 'gregorian_nls' calendar above and included some text warning people that
> > resolutions of < 1 minute are suspect, then we'd have a backward
> compatibility
> > path.
>
> Yes, I agree.
>
> > In fact, we could just use 'gregorian' to cover the 'gregorian_utc_lse'
> > case.
>
> Please could you help me to understand what this case is?
>
> 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.) I'm not committed to that name, by the
way. It is just a placeholder for that particular case.
In the previous email exchange to this one, regarding this
gregorian_utc_lse case, you had said
I think we have to support this case because it is almost certainly in
use, perhaps widespread use, and it's better to be explicit about it. CF does
not generally try to tell people what to do, but to enable them to describe
clearly what they have done.
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.
Best wishes
>
> Jonathan
>
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>.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150625/145520c0/attachment-0001.html>
Received on Thu Jun 25 2015 - 06:58:30 BST
