> 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"
I agree -- THAT case is currently handled (defacto) by "gregorian", and I think we all agree that we should clarify that in the docs. My concern is the "It matters to me, but I don't really understand exactly what the systems and libraries I'm working with do and what their limitations are" use case. And I think those folks would be poorly served by a CF standard that appeared to support their use case, but might give incorrect results. For the "I really know exactly what my requirements are, and I know that the tools I use satisfy them" crowd -- they can use proper TAI or a datetime library that handles leap seconds. As for the distinction between producers and consumers -- that is a big issue -- consumers are likely to be less knowledgeable, so you do want a way to tell them what to do with the tools they have access to. So the idea of a way to tell them: "decode this with a non-leap-second-aware library and you will get what you expect makes sense. @JimBiardCics wrote: > 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. Funny you should say this -- on the bus this morning, I was thinking about this, and realized exactly this -- the use case is: - I have a bunch of UTC timestamps (e.g. 2018-11-01T12:15:32) - I want to store them in a time variable in a CF compliant way - I want users of that file to get exactly the same timestamps back when they use the data. And the fact is that without the existence of leap seconds in commonly available libraries, it's actually hard to do that properly with the CF time-elapsed-since-a-timestamp. So the solution to this is to provide, in CF, a way to encode timestamps directly. ISO8601 strings are probably the easiest way to do it, but you could store them in a more compact binary format if you like (like the python datetime object does internally). I was part of the conversation a while ago about doing this, and did not support it because it seemed like simply another way to encode the same information. But I've come to the conclusion now that it is NOT the same information with a different encoding. Storing timestamps directly (as a string or other format) is a way to store not a time axis (with nice metric properties, etc), but to store, well, timestamps -- like "this measurement was taken at this date and time". So my personal opinion: 1) CF should accommodate the use-case Jim is advocating for. 2) The best way to do that is to have a format for storing timestamps -- maybe we could even call it "timestamp" or something, rather than "time". 3) If (2) is not acceptable to the CF community, then JIm's proposal is probably the only practical solution. NOTE: I have come around because I've come to a new understanding of the problem we are trying to solve. I thought it was: "We need a way for people to store data that are working with inappropriate tools for their use-case, that will create invalid data in the CF file, but that will probably be able to be recovered with standard tools" >From that perspective, you can probably see why I thought it was not a good >idea. Now I think the problem we are trying to solve is: We need a way for people to store precise-to-the-leap-second UTC timestamps such that they and their users will get the exact same timestamps back when processing the file" I imagine most of you will agree that that is a reasonable use-case for CF. Jim's proposal is a way to accommodate this use-case using the current CF approach to encoding datetime and commonly available tools. However, it is also a way that is prone to confusion, errors and hidden bugs. Thus I propose a way to directly store timestamps, which will address the problem at hand, in a clear and much less error prone way. I want to thank Jim for his persistence in continuing to push on this in the face of my intransigence :-) Final thought -- we have also brought up issues in this thread about whether to properly support TAI, etc -- maybe a new issue is in order for that? -- 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-435179676
