@martinjuckes @ChrisBarker-NOAA @JonathanGregory Part of our problem here is that we have multiple "calendars" that are in concurrent use in the current era for different reasons. We don't really have this problem with the Julian and Gregorian calendars. That problem was resolved around 400 years ago. The best equivalent today would be Gregorian vs the Islamic or Jewish (or Chinese?, etc) calendars, but I'm not aware of any significant level of use of these other calendars within scientific regimes. This parallelism is confusing.
The other part of the problem is that changes we make here could deprecate one of the most common means of working with time within the netCDF/CF framework. I could be wrong, but I think that most data producers and users will ignore us and keep doing what they have been doing. And I think we will be doing the community a disservice if we do that. There is a practical, unwritten, convention that has been in play since COARDS mandated time be stored as elapsed time since an epoch time stamp. That convention is naively converting UTC time stamps to values stored in the time variable, and retrieval of those time stamps by naively back-converting the values in the time variable. I think we need to honor the practical reality and give data producers and users a way to know without a doubt that this convention is being followed. What benefit is derived from telling them they shouldn't be doing what they are doing when it is working just fine for them? -- 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-436266823
