Dear all, [Sorry for joining in late, I am currently and for the coming two weeks travelling with only infrequent internet access].
I have just read Jim's invitation to the email list thread on 360_day months to come over here. In that thread I just waited for the email conversation a couple of years ago on calendars and TAI to come into play. But it happened here instead. Many thanks Jim for putting together the background text, it did a good job in structuring my thoughts on this. And I can only agree with Chris and Jonathan, this is a complicated thread and I am not sure that I have grasped the full depth of all aspects. Hence, the following questions of understanding: 1. If I understand previous threads and Jim's background text, the need for high-resolution linear (metric) time comes from the satellite community. Why is that (I know that satellites are moving at high speed)? If someone wants to compare a scene/pixel/vertical profile/etc. from time1 with the corresponding scene/pixel/vertical profile/etc. at time2, is really a 'few seconds' that important given the sampling granularity (i.e. how often a certain point is revisited and/or the spatial and temporal 'averaging' involved in acquiring the data)? Is it because i) the precise timing (as such) IS in fact important, or is it because ii) the precise timing determines the precise geolocation of the data (which is reasonable considering the speed of the platform)? If it is because of i) then it is clear to me that a highly precise linear (metric) calendar is needed. If, however, ii) is the underlying reason for this discussion I am not so sure. Is it the right way to go for CF to conceptually merge the need for spatial accuracy with the already complex machinery for CF calendar and time representation? Should not this be handled in the data preparation step. 2. Jim's background text states that "the synchronization of time stamps with the cycles of the planet, is where calendars come into play, and this is where things get ugly." I fully agree, and when we now are discussing in some depth the CF representation of time and calendars, I would like not to forget another important use case for CF, namely the climate modelling (or broader geophysical) communities. Here seconds is useful as a SI unit, but data requiring this precision is rare if at all existing (LES/CFD modellers using CF, anyone?). The two time units "day" and "year" both have specific geophysical meaning, where the current definition 1 day = 84600 seconds is to my knowledge perfectly all right for all models. But the (sort of) time unit "year" is differently but well defined in the model representation of the planet. And I would argue that this is such an important geophysical model and real world quantity that it should be better suppported by CF. In various threads over the years I have seen the argument that the Udunits time units month and year should not be allowed by CF. I understand the argument, I think, but just because it is difficult (so far) within the present CF and Udunits versions it should not be ruled out that easily. Could we penetrate this in some more depth now when dealing with these matters, or should it be another thread? 3. Mostly a comment: a while back there was a thread on "gregorian" calendar vs. "mixed_gregorian_julian" calendar. To improve clarity and precision in defined concepts and calendars, would it not be better to deprecate "gregorian" and "standard", and instead use "mixed_julian_gregorian" (julian first then gregorian). Otherwise it might become confusing if we end up with "gregorian", "gregorian_utc" and "gregorian_tai". Kind regards, Lars -- 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-435609575
