Correct error in introductory text of Section 4.4 -- definition of 'year'

[stevehankin]

1. Title

Correct error in introductory text of Section 4.4 -- definition of 'year'

2. Moderator

Steve Hankin

3. Requirement

just a factual error that out to be corrected. The change will have no further impacts.

4. Initial Statement of Technical Proposal

The intro to 4.4. Time Coordinate in CF is wrong where it says "The Udunits package defines a year to be exactly 365.242198781 days". This line should be corrected to say "The Udunits package defines a year to be exactly 365.2425 days"

Explanation: Udunits merely comments on the year length of 365.242198781 days. It actually defines the Gregorian year length to be 365.2425

See text at ​http://www.unidata.ucar.edu/software/udunits/udunits-1/udunits.txt.

# Interval between 2 successive passages of sun through vernal equinox
# (365.242198781 days -- see 
# http://www.ast.cam.ac.uk/pubinfo/leaflets/,
# http://aa.usno.navy.mil/AA/
# and http://adswww.colorado.edu/adswww/astro_coord.html):
tropical_year		P 3.15569259747e7 second
lunar_month		P 29.530589 day

common_year		P 365 day		# exact: 3.153600e7 seconds
leap_year		P 366 day		# exact
Julian_year		P 365.25 day		# exact
Gregorian_year		P 365.2425 day		# exact

[jonathan]

Dear Steve

Thanks for proposing this correction. Perhaps I overlooked earlier that udunits.dat (my copy of it, anyway), defines year=tropical_year. So that means udunits defines a year as 3.15569259747e7 seconds. It's awkward to convert this number into days! udunits defines a day as 86400 seconds exactly. So we have to divide 3.15569259747e7 by 86400 with 12 digits of precision. I can't get it to equal exactly what the existing text says, but it's not exactly 365.2425 either, because a year isn't a Gregorian year. Is your udunits the same?

Cheers

Jonathan

[stevehankin]

Jonathan,

I think we may be opening a Pandora's box that we only closed recently with some difficulty. Didn't we agree that the default interpretation of 'year' in CF should be Gregorian year?

If you agree this this is the case then I will follow up by proposing further word-smith modifications to the Section 4.4 introduction. At present the text merely gives a general caution about using units of 'year'. It should instead advise that Gregorian_year is the preferred udunit to choose if the concept of 'year' as a unit is desired. (Or have we already captured this thought elsewhere in the text?)

• Steve

[jonathan]

Dear Steve

I don't remember that. It might be a good idea to adopt Gregorian years, but I think that would arguably be a change to the convention, rather than correcting a mistake or clarifying the intention, because it would be a departure from udunits. In a CF version of the udunits database, which we have discussed but not so far provided, we could define year as Gregorian_year. I think we would need to do that, to be consistent, because of the use of udunits in conjunction with CF.

Best wishes

Jonathan

[stevehankin]

Section 4.4.1. Calendar of CF 1.6 ​http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#calendar states: Mixed Gregorian/Julian? calendar as defined by Udunits. This is the default.

It seems only reasonable to interpret the unit 'year' in the context of the current calendar. Any other definition of 'year' introduces internal contradictions. Of course, the mixed Gregorian/Julian? calendar creates a unique ambiguity, since it offers up two different definitions for 'year' (in parentheses here imagine an image of a human brain exploding).

CF has to specify some definition for 'year' in the mixed Gregorian/Julian? calendar. I'll assert (comments please) that the Gregorian definition of 'year' is the best choice. If agreed, this fact should be documented in the corrections to the introduction to section 4.4 (the topic of this ticket).

[jonathan]

Dear Steve

Sorry to be awkward, but I don't think we can do that. CF adopted udunits as the arbiter of how units should be interpreted, and redefining the unit of year would therefore be a backward-incompatible change. It would affect existing files if it was interpreted as applying retrospectively, even if that was not the intention.

In CF section 4.4 we currently recommend that caution is necessary with the units of year and month, because of the definition, which catches people out. I'd like to suggest that we change this recommendation to a prohibition of the units of year and month in the next version of CF. The CF checker could detect that, and we could remove these units from a CF version of the udunits database.

For uses where year and month are to be interpreted in a calendar-dependent way, we could introduce an alternative syntax for units of time, not related to udunits. John Caron suggested one a while ago, and has implemented it in Java I think, but it's not been put forward as a CF convention. This involves some extra rules e.g. to decide what is meant by 31 Jan 2013 plus 1 calendar month, or 29 Feb 2012 plus 1 calendar year.

Neither of the above could be done as a defect ticket, because they change the convention. If you or others think we should proceed with this, we could change the status of this ticket to make a new proposal, or start a new ticket.

Cheers

Jonathan