Dear Jim and Chris Thank for your latest exchanges. What I said before them is similar to what Chris says, I think.
(1) I used the name **gregorian_utc** for what Jim called **gregorian_metric**. In this calendar, timestamps (including the reference time) are UTC, and the conversion uses leap seconds. I think to call it "metric" could be confusing (although I understand why you choose that word) because "metric" might be understood to mean "not Imperial" i.e. not feet and pounds! :-) (2) What Jim calls **gregorian_nonmetric** is what is usually done for real-world data. The times are UTC but have been encoded without leap seconds. That's fine and workable. It's just an encoding, with the drawback that time is not exactly metric. (3) However, this same scheme is what is used for some models. They follow the real-world Gregorian calendar, but the model world has no leap seconds. Hence the encoding without leap seconds is accurate, and the times are exactly metric. I therefore still think that we should call both (2) and (3) **gregorian**, because that's no change from present. Their timestamps are UTC (or UTC-like if model) but their time conversions have no leap seconds and date-times for leap seconds cannot be encoded. We should call the new calendar (1) something else. We could call it **gregorian_leaps** for example, if **gregorian_utc** is misleading because (2) can also encode UTC. If we introduce this new calendar (1), we should prohibit the use of **gregorian** to mean this in future, so there will be no ambiguity for data written in future. As we have all said, we could also have a pure **gregorian_tai** calendar, in which timesteps are TAI, conversions have no leap seconds and times are metric. I think we *should* add this if there is a use-case for it. CF has often discussed introducing timestamps as an alternative to time coordinates, and equally often we've decided against it. I would appeal not to start that again - at least, not in this issue! Best wishes Jonathan -- 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-436029042
