I agree -- you want to get close to a consensus before a PR -- but it would be great to also have the proposal and issues all laid out in a doc, too, and it is the time for that: #150. AT this point, that doc could be anywhere that we all can see it.
Also -- could folks please respond to my idea of having a direct way to encode timestamps? Now comments on the lastest specifics: **gregorian_metric** : This sounds like UTC to me -- can't we simply call it UTC, with maybe specifically calling out that UTC leap seconds have been applied (and need to be accounted for to recover a UTC time). **gregorian** -- this is what we already have, and we have to live with whatever files are already using it. and while I think we need to accommodate ambiguity with regard to leap seconds, we probably should NOT continue to allow non-metric times in the time axis, in fact, did CF ever allow this? I expect that there are such datasets in the wild, but that doesn't mean they were valid. So if we decide to keep this, "non-metric" data shodl be considered legacy, and not OK for the future. It is OK, on the other hand, for the timestamp to be ambiguous with regard to leap seconds. In short, if you use "gregorian", and use the values directly in the units specified, all will be well. If you convert to a datetimestamp, the result may be off by up to 37 seconds (or more in the future...) **gregorian_nonmetric** -- I don't have any concise ideas, but we need a different name -- ideally, a name defines what something IS, rather than what it is NOT. That being said, teh text here is good, though I would re-arrange it -- start with what exactly it is, how it should be computed, and how it should be used, then mention consequences of that i.e. the non-metricity. WE als need to be clear as to what use-cases this should be used for -- i.e. you started with correct UTC datetimestamps, and want the user to recover UTC datetimestamps. i.e. the variable should not be used directly to compute elapsed time. also: " If the user wishes to obtain fully metric elapsed times from the contents of the variable, it is possible to do so using a leap seconds table and analyzing the time series to determine the points at which leap seconds may need to be added or subtracted in order to correct any offsets or non-linearities." I think this could be phrased to make it clear that what you need to do is first convert to datetimestamps without leap-seconds, and THEN convert to elapsed time with leapseconds, if that's what you really need. -- 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-435991400
