@ChrisBarker-NOAA >> People who are converting precise and accurate UTC time stamps into values >> in time variables using the tools most available to software developers for >> handling time without sensitivity to leap seconds are creating time >> variables that have the potential to be non-monotonic because of leap >> seconds. They have done it in the past, they are doing it now, and they will >> very likely continue to do so.
> Agreed -- and we need to accommodate that -- which we already do implicitly > with "gregorian", and we should make it explicit in the sense that the whole > leap-second thing is ambiguous. As I look at it, the case I am describing above is not the same as the "I don't know about all this and it doesn't matter to me" case. These are people for whom precise and accurate time matters to the level they are taking it, but they would be perfectly happy with storing the time stamps as strings instead of converting to elapsed time since an epoch. But CF mandates elapsed time since an epoch, so that is what they do. Their user base likely feels the same way. Precision is desired, but metricity is not an issue. When I think about all of this, I find myself looking at two slightly different category lists. One is for producers, the other is for consumers. For producers: 1. The distinctions are unimportant. (old **`gregorian`** is good enough) 1. Precision is important but metricity is not. The inputs to the netCDF creation process are accurate UTC time stamps. Using leap seconds to create fully metric and monotonic time variables imposes a burden on users to find software that handles leap seconds properly. (**`new calendar a`**) 1. Precision is important and metricity is important. The kind of input to the netCDF creation process doesn't matter, because they are going to do whatever it takes to generate accurate time variables. Their target users are going to do whatever it takes to use the time properly. (**`new calendar b`**) For consumers: 1. The distinctions are unimportant. (old **`gregorian`** is good enough) 1. Precision is important but metricity is not. As long as they can get accurate UTC time stamps they are happy. They would rather not deal with leap seconds if they don't have to. (**`new calendar a`**) 1. Precision is important and metricity is important. They likely want to do math with the elapsed time values themselves. Either new calendar works for them, because they are going to do whatever it takes to get what they need as long as they know what is in the time variable. (**`new calendar a`** is best, but **`new calendar b`** can be made to work) I agree wholeheartedly that the ideal scenario would be to insist that the contents of every time variable be fully metric and monotonic under all circumstances. I think the practical reality is that the vast majority of both producers and consumers fall in their respective categories 1 and 2. As kludgy as it is, I think it is a good idea to allow **`new calendar a`** (the calendar formerly known as **`gregorian_utc`**) as well as **`new calendar b`** (the calendar formerly known as **`gregorian_tai`**). -- 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-435071298
