@JonathanGregory I think we can likely leave LORAN-C off for now. There was the original request for GPS time, I have, myself wished there was a TAI time when I was building a dataset that depends on it.
I still think we should provide a path for data producers to clearly signal to their users that they can depend on the data in their time variables to produce (almost always) correct UTC times stamps if they follow the right prescription. The **`gregorian`** calendar, if modified as @JonathanGregory described above, could lead people to think that all time variables carrying this calendar follow that rule. There are, very possibly, time variables that have metrical time in them which are marked as **`gregorian`**, and it would be incorrect to treat them as if they didn't. As a specific example of a potential problem, if I know for a fact that my time variable is of the 'converted UTC time stamps' variety, I can use a leap second table to correct the values to make them metrical. If I do this to a file that came from a model or where the values were already metrical, I am going to get incorrect results. I think the **`gregorian`** calendar, with appropriate warnings added, is perfectly fine for modelers. As near as I can tell from the interwebs, this calendar doesn't speak at all to the question of leap seconds at all. The time naturally implied by this calendar is days, and the length of the second varies to keep exactly 86,400 of them in each day. -- 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-436681688
