Dear Jim Please could you elaborate on your reply to me? I appreciate, as Chris says, that this thread is long and complicated, like our previous email discussion was, so I may have missed something. However we do need to keep all this serial reasoning, I think. From time to time, the moderator (or the proposer, if there is no moderator, as is often the case) should restate where we have got to, in order to see if everyone agrees. Maybe I'm implicitly asking you to do that now.
I use the names tai and utc, as you first said, because they're more mnemonic than a and b. The names we eventually choose for the convention are a different matter. They don't have to be tai and utc. If I understood Martin correctly, I agree with him that timestamps should be interpreted in the calendar stated. That's what we do in model calendars, and with gregorian and julian. Apart from that point, I think I agree with what you proposed, don't I? gregorian_tai. No leap seconds in the conversion between time coordinates and TAI timestamps, reference time is a TAI timestamp, time coordinates are metric. gregorian_utc. Leap seconds in the conversion between time coordinates and UTC timestamps, reference time is a UTC timestamp, time coordinates are metric. gregorian (the existing calendar). For the real world, reference time is a UTC timestamp, but no leap seconds in the conversion between time coordinates and timestamps, and time coordinates are therefore not metric. Data written up to now with this calendar might or might not have allowed for leap seconds in the conversion (if it did, it was gregorian_utc). We don't know, but as you have argued several times, most applications don't require such precision, so it doesn't matter very much. (For the ones that do, we are providing the two new calendars.) For model data, reference time is UTC in the model world, conversion has no leap seconds, but the model world has no leap seconds, so the time coordinates are metric. How does that differ from what you have in mind? Cheers 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-435587942
