@JimBiardCics Thanks for that detailed reply. I think I understand now. I've also done a bit more background reading and learned how extensive this problem is, causing disruption to companies like Google and Amazon, who have both adopted messy (and mutually inconsistent) work-arounds to the problem.
I'd like to split this into two related problems: (1) the current CF convention does not fully explain how to deal with leap years, and does not distinguish between TAI time and UTC time; (2) users struggle with the available tools (which are not good) and we need to make things easier to avoid having repeated errors in the information encoded in our netcdf files; (1) is reasonably easy to deal with (at first sight) ... we need two calendars which differ by the leap seconds, so that `2018-06-01 12:00:00Z[calender A]` corresponds to `37 seconds since 2018-06-01 12:00:00Z[calender B]`. In this case the minute counter of calendar A would be of variable length. Calendar A and B would both be based on the Gregorian calendar. The only difficulty is that the translation from Calendar A to Calendar B is undefined for dates after 2019-06-30 -- for a standard such as CF this is problematic. There also appears to be a slight inconsistency in the convention between the introduction to section 4.4, which explains how the time stamp relates to UTC time, and subsection 4.4.1 (which you quote) which states that the time stamp will be interpreted according to the calendar. Perhaps this just needs a clarification that the introductory remarks only apply for specific calendars. There is a further complication in that Udunits neglects the leap seconds, so it is not accurate at the level you want to achieve here. (2) introduces some complexity, and I think this is where the idea of a "non-metric" coordinate comes in. In an ideal world we might deal with (2) by improving the available tools, but we don't know when the next leap second is coming (it will be midnight on June 30th or December 31st .. and almost certainly not this year ... but beyond that we have to wait for a committee decision, so nothing can be programmed in advance). What I think you are suggesting, to address point (2), is that we allow a construction in which `2 minutes since 2016-12-31 23:59:00` to be `0 minutes since 2017-01-01 00:01:00` and for these to be UTC times, so that the length of the `2 minutes` is 121 seconds. Consequently, any coordinate we defined through this kind of construction would be, in your words, a non-metric time. I can see the logic of introducing something of this kind, but (and this takes us back to the conversation in the [360 day calendar thread](http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020620.html)) I don't think we can do it in a variable with standard name `time` or use units which are defined as fixed multiple of the SI second. The `time` concept is already very busy, and the metric nature of time plays an important role in many aspects of the physical system. If you accept that this is a new variable I'd be happy to support the proposal (e.g. you suggested `abstract_time` in the email thread, or `datetime` is a common tag in libraries dealing with calendars). Similarly, having units of measure which have a fixed meaning independent of context is a firmly established principle in the physical sciences and beyond, so if we want a unit of measure which is a bit like a minute, but sometimes 61 seconds long, I'd be happy to accept this provided it is called something other than `minute` (and the same goes for hour, day, month, year). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-434251924
