Dear Jim > I appreciate your willingness to continue this attempt to find a > meeting of the minds about all of this. I hope you will forgive me > if I am not always completely clear in my attempts to express myself > or fail to understand you.
I would say exactly the same to you! Thanks. Actually I'm struggling to understand what we are disagreeing about. > As a data consumer, all I have to do is convert the reference time > from the stated calendar to my desired calender, then use that as > the basis for producing timestamps from the elapsed times in the > variable (using the correct set of time functions, of course). > Expressing the elapsed times as timestamps in one calendar and then > converting those timestamps to another is another way that you could > do it, but one which adds unneeded steps. In both our views, decoding the time coord (into components of time, which I will refer to as "timestamps" for convenience although we would probably not use strings for this purpose, since usually we want numbers) according to the calendar stated by the attribute requires using the algorithm appropriate for the calendar. This algorithm is one which can add an offset to the reference timestamp using the rules of the calendar to produce new timestamps, and the reverse. Hence the calendar attribute implies particular rules for encoding and decoding. But that is the statement of mine which you disagree with, I think - isn't it? I agree that the calendar attribute also states the calendar in which the ref time is expressed - this second function is one I have recognised because of our discussion (it is obvious in the case of model calendars, so I didn't see it as a distinct function). Since the att states the calendar of the ref time, and implies the rules for encoding and decoding, it therefore also inevitably implies the calendar of the decoded timestamps, doesn't it? I agree that you could change to a new calendar in the real world by calculating the difference in seconds between the ref time if it's interpreted in the old calendar and if it's interpreted in the new calendar (or a new ref time if you want to change the ref time as well as the calendar) and then adjusting the time coordinates by this amount (and the ref time in the units string if you want to change that as well). I think that will be the same as what I suggested, which is to decode the coords using the old calendar and ref time, then encode them using the new calendar and ref time. Perhaps my method sounds like more calculation, but it might be easier to carry out (just two subroutine calls). I think these methods are equivalent, aren't they? They work because, as we agree, the encoded time coord is also an elapsed time, and is useful as such. The only situation in which it might have small dis- continuities is if the no-leap-second algorithm is used to encode and decode UTC and, as we have agreed, there should be a clear warning against not doing that if precision <1 min is required. The reason that I regard timestamps as primary, and therefore suggest that one would go via timestamps to change the calendar, is because of the non-real- world calendars that are the subject of other emails. Although, as you rightly say, there is no exact way to draw an equivalence between the real-world and the various non-real-world calendars (360_day, no_leap, etc.), we have to draw such an equivalence for model-model and model-obs comparisons. The main purpose of CF is to clarify when and how data is to be regarded as comparable, and it's a common need to compare climate data in different calendars. When this is done, it's the timestamps which are comparable. DJF (season) is DJF (including all of Dec, Jan and Feb) whichever calendar is used, even though it has different lengths in those calendars. Therefore it is the timestamps which truly define the ranges of time, not the relative time coordinates. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
