> People who are converting precise and accurate UTC time stamps into values in > time variables using the tools most available to software developers for > handling time without sensitivity to leap seconds are creating time variables > that have the potential to be non-monotonic because of leap seconds. They > have done it in the past, they are doing it now, and they will very likely > continue to do so.
Agreed -- and we need to accommodate that -- which we already do implicitly with "gregorian", and we should make it explicit in the sense that the whole leap-second thing is ambiguous. >Telling a significant group of data producers that they must change their >software in a way that will cause widespread problems for their users is a >good way to get them to ignore you. Indeed. The question at hand is do we codify as correct what is, at best, a kludgy improper process? As we've all said, the ambiguity is a non-issue for the vast number of CF use cases. So the question really is -- are there folks for whom: - Leap-seconds matter - They know and understand the issues of UTC vs TAI, etc. - They have no way to produce a "correct" time variable I honestly don't know -- but it's been suggested that we can use UTC always as the timestamp, 'cause anyone that understands the distinction (and cares about it) will have access to a leap-second-aware-library. In which case, no -- there isn't a large user base. But given the dirth of leap-second aware libs, maybe we have no choice to to codify this kludgy encoding. -- 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-434816875
