Dear Jim and Martin Martin and I agree that the timestamp should be interpreted in the calendar stated in any new CF calendars, as in the existing ones. That means we need a new calendar for UTC timestamps converted with leap seconds (the second line in your table).
We need a TAI calendar (the first line in your table) if there is a use case for that - do people want to write CF-compliant data with reference timestamps in TAI? If the reference timestamp is in the calendar stated, your first two cases are different, because the conversion for TAI timestamps to time coordinates does not require leap seconds. It uses the "naive" algorithm, which is correct for TAI. What is "uncorrected GPS" (your third line)? I propose that we redefine "gregorian" to mean your sixth line for real-world data i.e. UTC timestamps converted to time coordinates without leap seconds. We should state that in this CF calendar it is assumed that there are always sixty seconds in a minute, so HHMMSS with SS=60 is illegal as a timestamp. The conversion between timestamps and time coordinates is reversible if this case is excluded, but the times are not metric. I agree with Martin that making "gregorian" more precise in this way is not problematic for existing data, whose intention is unclear. The "gregorian" calendar is also the correct one for models which use the Gregorian calendar. Hence I think we definitely need one new calendar to meet the need you identified. We might need two or three, if the second and third paras above are use cases for CF. Best wishes Jonathan -- 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-436265831
