Dear John > But by main issue is that in Example 7.8 the "time" data entered in > the file is still described as having units "days since 1960-1-1" > which really isn't so. It is equally logically "days since 1991-1-1". > In reality it's just "days since Jan 1 of any year".
Yes. > This convention doesn't prevent the practice of assigning time values thus: > > double time(time); > time:units="days since 1960-1-1"; > data: > time = 15 45 75 ... > > double time(time); > time:units="days since 1959-1-1"; > data: > time = 380 410 440 ... > > udunits would consider these times to be identical, but for a monthly > climatology starting the counting at 380 is just nuts. What you say is correct; these are equivalent. I think the issue is that you don't need to impute any meaning to the reference time that is used in the units string. It is arbitrary. It could be anything. The only point of it is to encode components of time (year, month, day, etc...) into numbers. The climatological interpretation of these date-times is based on what they mean when decoded into components. Once they are in components, the units string - both the unit and the reference time - are irrelevant. They are not needed any more, because they do not contain any extra metadata. CF climatological time bounds encode, in a compact way, both the range of years used to compute the climatology, and the time within the climatological year. You're right, they do not indicate the weighting used to compute a time-mean or other statistic. This is generally the case for all kinds of axis, not just climatological time. cell_methods provide a way to record, in a non-standardised way (in brackets) a comment about the weights. So far no-one has raised a need for a standardised way to do this. Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata