# Clarification of requirements on calendar attribute of a bounds variable # Moderator None at present # Moderator Status Review [last updated: 2020/05/07] Just posted # Requirement Summary Express clearly what constitutes a valid value for the `calendar` attribute of a bounds variable. # Technical Proposal Summary Clarify the text in [Section 7.1](http://cfconventions.org/cf-conventions/cf-conventions.html#cell-boundaries) expressing the requirement for equivalence of attributes between bounds and associated coordinate variables. # Benefits People using the CF convention to describe coordinate bounds. # Status Quo In [Section 7.1](http://cfconventions.org/cf-conventions/cf-conventions.html#cell-boundaries) of the current standard it is stated that the `calendar` attribute of a bounds variable, together with other listed attributes, "must always agree exactly with the same attributes of its associated coordinate". This appears clear, but there is some ambiguity because `noleap` and `365_day` values for the `calendar` attribute have exactly the same meaning. Some CMIP6 data, for example, has been provided with time coordinates using one form and the bounds variable using the other.
**Does the reference to exact agreement in the standard mean agreement in string value, or agreement in meaning?** The other attributes referred to in the same sentence are `units`, `standard_name` and `positive`. The same issue could arise with the `units` attribute, in that it is possible, in many cases, to express the same logical unit with a range of different string values. I do not have a strong preference here .. but it appears simplest, both in terms of the structure of the standard and the keeping things simplest for users, to insist on an exact match of the attribute values. # Detailed Proposal Replace "must always agree exactly with" with "must exactly match the values of". -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265 This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
