“ I think we need to go ahead and embrace the mess that quite a few data producers and users are happily using.“
How about we “accommodate” the mess, rather than embracing it? I see your point: folks have datasets and processes in place now. If they can make their files correct and clearly defined by simply changing the value of one attribute, then they are likely do it that, rather than having to change code in their process or re-write the variables. So we should provide an official way to do that. However, it does not have to be the recommended way to do Store UTC timestamps. I think we should have a new recommended way to store timestamps, but that is kind of a separate issue — it will only effect a tiny bit of the docs. I’m on a phone, so lost track a bit of alll the calendars on the table, but I think we need to, in the documentation, focus on two things: If you have this use case, you should use this calendar. And If you are reading a file with this calendar, you should process/interpret the data this way. (perhaps Jeff’s cf-time lib can be a reference implementation) That means that the “metricity” of the timestamps should be discussed as a sideeffect in a warning, but not used as a description of the data) I also think that we should not make any assumptions about how “most people” or “most datasets” have processed their data. This means that maybe they’ll be one extra cakendar than we strictly need, but it also means that we can go for award with no ambiguity (or at least only well-defined ambiguity - how’s that for an oxymoron?) -- 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-436324231
