Hello All, @JonathanGregory has made a good summary as far as I can tell. However, I would prefer to see calendars defined in terms of what they are, rather than what they are intended to achieve. My understanding is that the additional calendar Jim and Chris are supporting would allow people to record UTC time stamps accurately (with the exception of time stamps that actually coincide with a leap second) without having to worry about leap seconds. What appears to be needed is an array of floating point number which represent a sequence of UTC timestamps, each time stamp being calculated from the reference given in the units string as if there were no leap seconds. This use case is not covered by the examples Jonathan supports. I would be happy to support this additional use case if the resulting variable was not assigned a CF standard name `time`. Others feel that it is close enough to time to carry that name. This would break backward compatibility in that the elapsed time between to values in a variable with standard name time would in future be potentially dependent on the value of the calendar attribute.
Broadening the use case beyond the narrow objective of recording time stamp information (e.g. by saying it is for people storing observational data) introduces further ambiguity, and appears to be based on assumptions about how the data is being managed between measurement and encoding. regards, Martin -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-437438315
