> The elapsed time within the calendar system is 120 seconds, the elapsed time > between the UTC time stamps in the real world is 121 seconds because of the > leap second. So, if we have this data in the CF convention, which do we think > is the correct elapsed time? I've seen comments from Jonathan that suggest to > me that is should be considered as 120 seconds .... because that is what has > been entered in the file. I've also seen comments that appear to imply that > 121 seconds should be considered as correct.
121 seconds is correct. period, end of story. That is the ENTIRE point of Jim's proposal! > I would prefer the first interpretation, as we would then have a CF data file > that is internally consistent. But then we have no way to recover the actual UTC timestamp. This is why I have suggested that it would be better to directly store timestamps. Back to use case: the point of this new "calendar" is to be able to store and recover UTC timestamps without requiring leap-second-aware software on either the producer or consumer's end. The downside is that you have a variable that nominally has real time units (e.g. seconds), that almost, but not quite, actually represent seconds. If we do this, the docs need to make it clear that the variable is intended to be used to recover UTC timestamps, and not to compute timedeltas. Which, now that I think about is, is a good reason to use a new calendar, rather than another attribute -- it makes a clearer distinction. -- 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-437081624
