Hello, @JimBiardCics , @ChrisBarker-NOAA , Jonathan points out that the timestamp is usually interpreted in the calendar stated [in a comment added 3 days ago](https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-435587942). I think it is the case that all existing calendars supported by CF were created outside CF. This is clearly true for the Julian and Gregorian calendars created by Julius Ceasar and Pope Gregory respectively. Other calendars, such as the 360 day calendar, came from the climate modelling community. Adding support for TAI and UTC calendars would follow this pattern of providing a mechanism for encoding information in calendar systems which have been defined by others.
All the existing calendars use a common framework for mapping instants in time into a YY-MM-DD hh:mm:ss time stamp and back, with a fully reversible mapping. Your proposed calendar introduces a mapping which is not reversible (`2016-12-31T23:59:60Z` and `2017-01-01T00:00:00Z` both map onto the same value of the time variable in the example @JimBiardCics gives above). I'm puzzled by the suggestion that we shouldn't worry about this because it only happens at a few leap seconds. Isn't the point of this discussion to handle leap seconds accurately in the convention? I haven't been able to find a clear definition of "non-metric" in the discussion above. Would this be a good definition, that the mapping between time stamp and time since epoch is not reversible? I agree with Jonathan that this encoding issue is not really a change of calendar. There will also be people getting their time values one hour wrong because of failing to encode the spring and autumn clock changes properly -- but that is a problem the users need to sort out, the convention is clear. As Jonathan points out, models use a fixed 86400 second day, which resemble the TAI calendar, and we need to support this. Chris [writing in from the CF list](https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-434723577) [I'm not sure who this is] points out that the true Gregorian calendar has been defined by BIPM as including leap seconds, whereas CF refers to fixed days. There appear to be divergent views on whether `gregorian`, as a CF calendar identifier can be made into a precise term or not. One view is that we want to upgrade the definition to take into account emerging requirements for higher precision, and a 2nd view is that the term has been ambiguous in the past, so it has to stay ambiguous. As far as I can see, giving the term a precise meaning which is within the range of its possible interpretations does nothing to undermine past data. Data written when this term had an imprecise meaning will always lack that precision, whatever we do. -- 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-436215565
