Dear all I have drafted a new version of the affected parts of the text of Sect 4.4, taking account of the comments made since the pull request was revised, mostly as suggested but not quite, as follows:
* I included the deprecation of `gregorian` from [issue 319](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/319__;!!G2kpM7uM-TzIFchu!kHDysJNVstCmPKrjgVZu8iGy0cc7fbJEW1NTOYHL3ekfzp10A7YgFGp9nCHItTTQtHSRamXA_98$ ). * I suggest we insert the paragraph with rules about years before 1 just before the list of calendars, rather than the earlier place where it appears in the PR. That follows Martin's point that it's easier to deal with the detail in one place. If we put it here, I don't think we need to insert the prohibitions into the definitions of individual calendars. * I don't think we need to talk about year 0 = 1 BCE etc. because we don't allow years before 1 in the `standard` and `julian` calendars (except for climatology). I don't believe it is correct to say that year 0 in `proleptic_gregorian` is 1 BCE, because that calendar doesn't have the right year lengths. It is not a "real-world" calendar. * As Karl suggested, I avoided using Gregorian to describe other calendars, because they're not. * I stated the Julian rule for leap years, and that we use Gregorian month lengths in all calendars except `360_day` and `none`. * I included Karl's text for the cell methods section, with small changes (in bold) from his version. I say that it is impossible, rather than forbidden, for the year-0 convention to be used for climatological time in calendars where it's a valid year. I think the reference to `udunits.dat` is out-of-date, isn't it? What should it be changed to? Best wishes Jonathan ## 4.4 Time coordinate Variables representing time must always explicitly include the `units` attribute; there is no default value. The units attribute takes a string value formatted as per the recommendations in the Udunits package [UDUNITS](https://urldefense.us/v3/__http://cfconventions.org/cf-conventions/cf-conventions.html*UDUNITS__;Iw!!G2kpM7uM-TzIFchu!kHDysJNVstCmPKrjgVZu8iGy0cc7fbJEW1NTOYHL3ekfzp10A7YgFGp9nCHItTTQtHSR7FbfDcs$ ). The following excerpt from the Udunits documentation explains the time unit encoding by example: > The specification `seconds since 1992-10-8 15:15:42.5 -6:00` indicates second > since October 8th, 1992 at 3 hours, 15 minutes and 42.5 seconds in the > afternoon in the time zone which is six hours to the west of Coordinated > Universal Time (i.e. Mountain Daylight Time). The time zone specification > can also be written without a colon using one or two digits (indicating > hours) or three or four digits (indicating hours and minutes). The acceptable units for time are listed in the [udunits.dat](https://urldefense.us/v3/__http://www.unidata.ucar.edu/software/udunits/__;!!G2kpM7uM-TzIFchu!kHDysJNVstCmPKrjgVZu8iGy0cc7fbJEW1NTOYHL3ekfzp10A7YgFGp9nCHItTTQtHSRMXeF8AE$ ) file. The most commonly used of these strings (and their abbreviations) includes `day` (`d`), `hour` (`hr`, `h`), `minute` (`min`) and `second` (`sec`, `s`). Plural forms are also acceptable. The reference date/time string (appearing after the identifier `since`) may include date alone; date and time; or date, time, and time zone. The reference date/time string is required. ... ### 4.4.1 Calendar A date/time is the set of numbers which together identify an instant of time, namely its year, month, day, hour, minute and second, where the second may have a fraction but the others are all integer. A time coordinate value represents a date/time. In order to calculate a time coordinate value from a date/time, or the reverse, one must know the units attribute of the time coordinate variable (containing the time unit of the coordinate values and the reference date/time) and the calendar. The choice of calendar defines the set of dates (year-month-day combinations) which are permitted, and therefore it specifies the number of days between the times of `0:0:0` (midnight) on any two dates. **Date/times which are not permitted in a given calendar are prohibited in both the encoded time coordinate values, and in the reference date/time string. It is recommended that the calendar be specified by the `calendar` attribute of the time coordinate variable.** ... The values currently defined for `calendar` are listed below. In all calendars except `360_day` and `none`, the lengths of the months are the same as in the Gregorian calendar for leap years and non-leap years. In the `julian` and the default `standard` mixed Gregorian/Julian calendar, dates in years before year 0 (i.e. before `0-1-1 0:0:0`) are not allowed, and the year in the reference date/time of the `units` must not be negative. In these calendars, year zero has a special use to indicate a climatology (see [climatological-statistics]), but this use of year zero is deprecated. In other calendars, years before year 1 are allowed. `standard`: Mixed Gregorian/Julian calendar as defined by Udunits. This is the default. A deprecated alternative name for this calendar is `gregorian`. Year 1 in this calendar is year 1 AD or CE of the Julian calendar. `proleptic_gregorian`: A calendar with the Gregorian rules for leap-years extended to dates before `1582-10-15`. That is, a year is a leap year if either (i) it is divisible by 4 but not by 100 or (ii) it is divisible by 400. `julian`: Julian calendar, in which a year is a leap year if it is divisible by 4, even if it is also divisible by 100. `noleap` or `365_day`: A calendar with no leap years, i.e. all years are 365 days long. `all_leap` or `366_day`: A calendar in which every year is a leap year, i.e. all years are 366 days long. `360_day`: A calendar in which all years are 360 days and divided into 30-day months. `none`: No calendar. The `calendar` attribute may be set to `none` in climate experiments that simulate a fixed time of year. The time of year is indicated by the date in the reference date/time of the `units` attribute. The time coordinate**s** that might apply in a perpetual July experiment are given in the following example. ... Replace the paragraph in 7.4 beginning "The COARDS standard" with For compatibility with the COARDS standard, a climatological time coordinate **in the default `standard` and `julian` calendars** may be indicated by setting the time coordinate's units attribute to midnight on 1 January in year 0 (i.e., `since 0-1-1`). **This convention is deprecated because** it does not provide any information about the intervals used to compute the climatology, and there may be inconsistencies among software packages in the interpretation of the time coordinates with a reference time of year 0. Use of year 0 for this purpose is **impossible in all other calendars, because** year 0 is a valid year. Modify conformance document section 4.4 recommendations: * The use of time coordinates in year 0 and reference date/times in year 0 to indicate climatological time is deprecated. Add to conformance document section 4.4.1 recommendations: * A time coordinate variable should have a `calendar` attribute. * The value `standard` should be used instead of `gregorian` in the `calendar` attribute. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/298*issuecomment-865198435__;Iw!!G2kpM7uM-TzIFchu!kHDysJNVstCmPKrjgVZu8iGy0cc7fbJEW1NTOYHL3ekfzp10A7YgFGp9nCHItTTQtHSRrYXthb8$ 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].
