@JonathanGregory wrote: > What I propose is that data written with the next version of CF (in which we > have made the calendar changes) will have no ambiguity.
That would be nice -- but I simply don't think is possible / practical. Many, many, users do not understand (or even know about) leap-seconds, TAI vs UTC, many libraries do not support leap seconds, and if they do, users probably don't know if they do or what the implications are. So we need to have a way to encode time that says: these data are ambiguous with regard to leap seconds, and I don't care. And that's what the current gregorian calendar effectively is -- the problem is that folks that DO care have no way to express their data. I do think that it would be good to to say that a correct "gregorian" time variable be "metrical", though as there are existing data sets where that is not the case, I'm not sure if CF can say that a file is compliant with CF x.y, but not CF x.y+1 > UTC time which is written without leap seconds (and therefore non-metrical > for some intervals) is gregorian. So you will always know how to decode the > time coordinates correctly, won't you? no -- because the datetimestamp may or may not include (some) leap seconds, and you don't know whether the producer intended it to be decoded with or without leap seconds. I fear that there must be something in what you write which I haven't interpreted properly. > > Yes, the model gregorian calendar has days which are always 86400 seconds. > The days are always the same length, but the length of the second does not > vary. This is not the real world! > > -- 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-436748497
