Hi all,
I haven't followed all this as closely as I would have liked, but will
hazard some comments anyway:
1. I think we should require that elapsed time (recorded by the
time-coordinate in CF files) be correct no matter what the calendar. So
samples taken at a specific interval have identical time-differences
(calculated from the difference between successive time coordinate
values) whether or not the a leap second was introduced (or dropped?) or
not.
2. I think we should allow for basetime (the reference time stamp) to be
recorded either as UTC or GPS. Absence of either of these would imply
"GPS", which will therefore apply to all data written until now under CF.
3. Folks *generating* CF files should use algorithms that correctly
convert their timestamps to elapsed time (which is recorded in the
files). Then users can regenerate the timestamps correctly by looking
at whether UTC or GPS (or neither) appears.
4. Couldn't all of the above be simply accommodated with a single
"gregorian" calendar, but with the basetime (reference time stamp in the
units attribute) including either "UTC" or "GPS" at the end (or neither
for compatibility with previous written CF data)? Examples: "days since
1990-1-1 0:0:0UTC" or "days since 1950-1-1 0:0:0 GPS" (which would be
equivalent to "days since 1950-1-1 0:0:0"
5. Data would not be considered CF-compliant if the elapsed time
(recorded by the time coordinate) were incorrect because it had been
incorrectly converted by the data provider. "UTC" would indicate that
the basetime and conversion of elapsed time to timestamps should follow
the rules of UTC and include leap seconds. "GPS" (or absence of "UTC"
for backward compatibility) would indicate that thebasetime and
conversion of elapsed time to timestamps should follow the rules of GPS
and *not* include leap seconds.
I'm sure I have missed some important use case where the above simple
scheme would be inadequate. (Or perhaps I'm just completely out to
lunch, in which case please forgive me).
best regards,
Karl
On 6/29/15 9:21 AM, Jonathan Gregory wrote:
> Dear Tim and Nan
>
> If I have understood correctly, I think your two emails suggest that we do need
> a distinction of the precise and imprecise cases. As usual, I believe that CF
> should not prescribe to users what they should do; its aim is to allow them to
> describe what they have done. Different levels of precision are needed for
> different datasets.
>
> Following the emails that Jim and I exchanged, we could distinguish:
>
> gregorian: Real world-times, but without specifying whether UTC or GPS
> timestamps are intended, nor whether the encoding was done with or without leap
> seconds. The decoded times could differ by several seconds from UTC. I think
> this is Nan's use-case.
>
> gregorian_nls: UTC timestamps were encoded without leap seconds, with a
> reference UTC timestamp. I think this is Tim's use-case. This is not accurate
> according to UTC but it can be decoded precisely as intended. Jim points out
> that it's not a real-world calendar, but it's not far off.
>
> Have I correctly described these as your cases?
>
> In addition, we propose two other calendars:
>
> gregorian_utc: The encoded and reference timestamps are UTC, and the encoding
> is done with leap seconds allowed for. Hence the time coord is an accurate
> elapsed time.
>
> gregorian_gps: The encoded and reference timestamps are GPS, and the encoding
> is done without leap seconds. Again, the time coord is accurately elapsed time.
> I think this is the use-case which originally started this thread!
>
> Best wishes
>
> Jonathan
> _______________________________________________
> 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/20150629/f8075db3/attachment.html>
Received on Mon Jun 29 2015 - 12:00:41 BST
