Dear Jim and Chris I know you're not comfortable with it, but you're not being asked to tell people it's OK actually! :-) The CF convention is mostly for allowing people to describe clearly what they've done, not tell them what to do. It is perfectly fine, and usual, for particular projects which mandate CF to specify more restrictive rules about what should or should not be be done. I think that most people who encode real-world times are doing so with the no-leap-second calendar. You are also right to point out that the timestamps they are encoding may themselves be slightly wrong because they might have been decoded with the no-leap-second calendar even if they were supposed to be UTC. So the situation is unclear, as you say. This second problem applies even if the data-producer thinks they are encoding UTC times with leap seconds. I prefer to call it gregorian_nls because that is a way the data-producer can record what they have done in encoding the time coordinate. At least they should know that!
Yes, I think it is fine to point out that if the calendar is gregorian_nls, the time coordinates may be imprecise by up to a minute, say, so differences between them should not be depended upon for high accuracy. While not happy, would you agree to introduce gregorian_utc, gregorian_gps, gregorian_nls, define gregorian = gregorian_nls and deprecate it? I think we should omit gregorian_tai (although it's been instructive to discuss it) since it's not been asked for yet. Although I agree it could be done, I don't see why one would use gregorian_gps before its epoch. Does anyone have a present use-case for that? If not, I don't think it should be allowed to refer to times before the GPS epoch. If it is needed subsequently, we can introduce proleptic_gregorian_gps then, and decide what it means according to the use-case presented. > >so the Calendar is ONLY for defining the reference > >timestamp in the units. I don't agree still with this. The calendar specifies the time system for the reference time-stamp and the decoded time-coordinates, I have learned, and it also specifies how the translation is done. I recognise that these are distinct functions of it, but it's more convenient to achieve both with one attribute, since you can't vary these aspects separately. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
