@JimBiardCics : I'm sorry if I misrepresented your views, but I think I have understood, I'm just using different words. In the case 2b in your comment [a few hours ago](https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-436722293) you refer to data encoded as if there are no leap seconds. For data encoded in this way, `x seconds since time-stamp_0` is equivalent to a `time-stamp_1` calculated on the basis of fixed 60 second minutes, fixed 86400 second days. In addition, you are saying that `time-stamp_0` in this calendar system **is** the UTC time-stamp. I'm calling this relationship between the time stamp in the new calendar system and the UTC time stamp a mapping.
I think we could find a CF solution to these different perspectives, and also perhaps address concerns about implications for past data, by adding a new attribute to express the relation between the calendar time used in the file and UTC time. There are at least 4 different options for converting from UTC to a calendar with fixed lengths days which have been discussed in this issue: - TAI: the time stamp is offset: convert to UTC by subtracting leap second count; - GPS: as for TAI, but with an additional fixed offset; - Jim case 2b: use the same time stamp; - model: not really defined .... might as well use the same time stamp; If we add a new attribute (e.g. `utc_conversion`) which can take one of the values `tai`, `gps`, `model` and a 4th for Jim's use case (e.g. `direct`), this would cover all use cases, I think. If undefined, as it would be for historical data, the interpretation would be fuzzy, as it is now. With this approach, the case 2b would be covered by `calendar = "gregorian_fixed"` and `utc_conversion = "direct"`. -- 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-436758942
