@JimBiardCics wrote: > The satellite community needs highly accurate time > ... > They want to be able to tell their users that the elapsed times in the time > variables are precise and accurate, with no jumps or offsets.
Now I'm confused -- this sure sounds like we should have a calendar that clearly specifies TAI time to me. Which seems like a no-brainer to me: if you have a time access in TAI time, you know for sure that no leap seconds have been applied, and that you should not apply any leap seconds. period end of story. > I personally think that the current gregorian calendar is sufficiently well > defined and doesn't cause problems. also a bit confused here -- is this what you have referred to in the past as "ambiguous with regard to leap seconds"? -- in which case is "doesn't cause problems" in reference to themodleing community, which I agree is true, because: 1) seconds resolution is not usually required and 2) models usually *start* with a "timedelta since an epoch" representation that is natural and easy to encode in the current CF gregorian calendar. > The gregorian + extension form, assuming we use it, is providing further > guidance for users on specifics on how to handle the contents to get accurate > time stamps. I'm open to other names. So this is addressing the problem if how to store (and recover) datetimestamps that are true UTC, that is, with leapseconds embedded in them, but to do it with tools that don't support leap seconds. Personally I think encoding those as timedelta since an epoch, where the epoch is UTC, but the delta have been converted without leap seconds, is kludgy, confusing, pedantically incorrect, and prone to error. It is, on the other hand, pretty well defined, usable with commonly available tools, and will mostly "just work" for folks with this issue. I haven't heard (or noticed -- long thread!) anyone's response to my idea that we solve that problem with a way to encode datetimestamps directly (probably as ISO strings). I think that's the way to go -- it directly solves the problem at hand with no kludgyness or ambiguity. The only dowside I see is that folks may be tempted to encode time axes this way when they really should be using the current CF approach. However, if folks don't want to add a "datetimestamp" encoding, then im's proposal is our only option that will actually solve the problem at hand. We will need to be very careful about naming and documentation, though: gregorian_with_UTC_timestamp_deltas_computed_without_leap_seconds_convert_back_to_timestamp_without_leapseconds. is maybe a touch too long :-) perhaps gregorian_kludgy_leapseconds ? -CHB -- 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-435962420
