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. > 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. +-----------------------------------------------------------------------------+ | 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? Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
