Dear Jim It appears that we have some irreconcilable differences in interpretation but I am not sure that they make any difference in practice, which is fortunate if correct.
> The definition of a calendar includes (by implication) the rules for how > to convert between an elapsed time count since a reference epoch and > a timestamp as expressed in that calendar. Yes. The elapsed time count is the time coordinate. That's what I mean by the rules for encoding and decoding. In addition, the calendar attribute states the calendar of the reference time. (I can't understand why taking these together doesn't mean that the attribute implies the calendar of the decoded timestamps too, but I don't mind if we don't say that! I've always assumed that the calendar is regarded as a property of the time coordinate construct as a whole, because it's an attribute of the time coordinate variable.) Yes, I agree that you can change the calendar without modifying the time coordinate values if you instead alter the reference time so that it refers to the same instant of real time in the new calendar. (I was considering the case when you wished to keep the same reference time, say 1st Jan 2015, but alter the calendar. In that case you have to add an offset to the coordinate values, which can be done be decoding and reencoding or by other means, but the method used isn't material to the definition, so there is no need to say how this is done.) > Matching timestamps without conversion is exactly what you would > *not* want to do when comparing observations recorded using two > different real-world calendars. That is true. But it is exactly what you do want to do when comparing real- world and model calendars, or different model calendars, which is the common case for a lot of CF data. In that common case, the timestamps are primary. For example, climatological means, for which we have a CF conversion, assume that users want to deal with time in a timestamp-based way, in which months are equivalent regardless of calendar. It is inexact in a sense, but it's what we need to do. More generally, you could argue that CF is quite a lot concerned with the general problem of comparing apples and quinces. CF provides metadata which enables users to indicate that the comparison is valid, by giving the two things the same label. I don't think the question of whether timestamps are primary makes a material difference to the convention or its use. It would be fine to state that the encoded time coordinate is an elapsed time and has no discontinuities, except for small ones in the case of using the no-leap-second calendar to encode UTC time. I think we have to support this case because it is almost certainly in use, perhaps widespread use, and it's better to be explicit about it. CF does not generally try to tell people what to do, but to enable them to describe clearly what they have done. I agree that seconds are always the same length. If only days were too! (But they are in udunits, so we could warn against using days as a unit of time in calendar="gregorian_utc" because it could be confusing, although encoding and decoding would work correctly.) Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
