@martinjuckes I appreciate your concerns. I think that the two new calendars I have proposed provide a clear path for anyone who needs to do metric math with time.
**`new calendar a`** signals to a user just how they should go about getting to metric times from the time variable contents if they need to do that. They will need a leap seconds file and appropriate software, but they can do it with no problem. **`new calendar b`** signals to a user that the time variable contents are already metric. It also signals to a user that if he is interested in getting UTC time stamps, he will need a leap seconds file and appropriate software. **`new calendar a`** also signals to a user that doesn't need to do metric math with time that she can simply convert the elapsed times to time stamps without need for leap seconds files or extra software. Let's consider the situation we have now, where the only game in town for current data is, effectively, **`gregorian`**. Users have no idea how to handle the times. If accuracy to the 1 - 37 seconds level is required, users have had to obtain information from the data provider, figure out what is going on through experimentation, or are unaware of the reason their results are sometimes off. Educating people about time systems and encouraging them to use "smarter" software is a good thing. Writing CF conventions in such a fashion that we make them too difficult to use in the name of consistency is not a good thing. I know it doesn't sound like it is "too difficult", but the scientists I work with have a hard time dealing with a number of aspects of CF. I feel confident they would throw their hands up if told they had to start using software that knew how to handle leap seconds. -- 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-435511718
