Hello Jim, thanks for directing me here from the mail list discussion on [360 day calendars](http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020620.html).
As you might guess from my latest contribution to that discussion, I have reservations about relaxing the specification of `time` to allow a non-metric interpretation. Introducing a system which makes the interpretation of the `units` dependant on the value of an additional attribute looks like a substantial step to me, and I can't see any justification for it. I'm not sure if I understand the comments in your proposal about non-metric time values. Take, for example, a short period spanning the last leap second, which occurred at 2016-12-31 23:59:60. As a result of this leap second being inserted `2 minutes since 2016-12-31 23:59:00` should be `0 minutes since 2017-01-01 00:00:59` rather than `0 minutes since 2017-01-01 00:01:00`. This may be counter-intuitive, but the measure of time in minutes is still metric. The minutes counter in the time stamp is not enumerating constant intervals of 1 minute, just as the year counter is not enumerating years of constant length (the Gregorian year, neglecting leap seconds, is 365.2425 days, while the counter in the time stamp sometimes represents an increment of 366, other times 365). Software often adopts a simplified relationship between the counters in the time stamp and the metric time. An extreme case of this is the 360 day calendar we have been discussing on the link I mention above .. in which we have 30 days to the months and 12 months to the year, so that all counter increments relate directly to specific time intervals. My understanding is that by default the time stamp (the date following `since` in the units string) follows ISO 8601, which does include leap seconds. However, the leap seconds are not in the UDUNITS software, so we don't have an easy way of making use of this. The current CF convention implies that the interpretation of the units string follows UDUNITS, and UDUNITS **always** treats the time stamp as being in the standard Gregorian/Julian calendar. I have the impression that this is not always the intended meaning ... but would be a diversion from this thread. All the references I've found indicate that the time elapsed in the UTC system is exactly, by definition, time elapsed as measured by the atomic clock. The only difference is that UTC includes a concept of days, hours, and minutes, and the `UTC minute` does not have a constant length. It seems to me that the distinction is between the Julian/Gregorian calendar, in which the interval between `2016-12-31 23:59:00` and `2017-01-01 00:01:00` is 120 seconds, and the standard UTC calendar, in which this interval is 121 seconds. Wouldn't it be sufficient, as far as the CF standard is concerned, to recognise that the Gregorian/Julian calendar is no longer `standard` .. and perhaps introduce the term you suggest, `gregorian_utc`, as a new alias for standard? There is a separate problem concerning the UDUNITS implementation ... but if terminology is agreed here, we could discuss that on the UDUNITS repository issues. -- 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-433891857
