Dear Jonathan, all, Just to repeat a remark that Steve Hankin made whose implications have not been explored in this discussion: different countries adopted the Gregorian calendar at different times. (Greece didn't adopt it till 1923!) So what is considered a valid Gregorian date varies from country to country (and some of those countries don't even exist any more, or at least the boundaries have changed...)
This has two main implications: 1. I don't agree with the proposal for a "strict Gregorian" calendar - the proposed switchover of 1582 is largely meaningless. 2. The non-proleptic Gregorian calendar is extremely problematic for historical observations as well as for models (astronomers use the Julian calendar consistently for this reason). Also, there are a couple of ambiguities in CF, which have also been brought up before but not resolved. Time axes are recorded as a sequence of numbers representing a certain number of intervals since a specified datum. The datum is part of the units string of the time axis and is recorded in a kind of pseudo-ISO format (e.g. "1970-1-1 0:0:0"). Should the datum always be interpreted as a date/time in the mixed Gregorian/Julian calendar (as specified by UDUNITS) or in the calendar system specified in the CF file (which would probably be more sensible)? Also, should interval lengths (e.g. months and years) be interpreted as the UDUNITS lengths (this is specified in CF but is not always helpful) or should these vary by calendar (which is again perhaps sensible, and some data providers do this)? Hope this helps, Jon -----Original Message----- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: 09 December 2012 15:46 To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] CF calendars (was: problem with times in PSD dataset) Dear Cecilia Thanks for your posting. Are we in agreement? I think that we are. > However, the current default is also problematic - reasons I see are: > 1) it does send a message to modelers who find the default unusable, > 2) because different calendar defaults are used on the modeling and > data side, current tools are limited to particular calendars, > affecting users, and 3) the mixed Julian-Gregorian calendar is an ugly > beast to peg as the standard forevermore. I agree with these drawbacks. If CF only dealt with the real world, obviously the real-world calendar (mixed Julian-Gregorian) would be the default and only calendar it had to deal with. However, at its outset CF was for models, many of which do not use this calendar, which was nonetheless chosen as the default because of udunits. I agree with you and others that providing such an inconvenient default is unsatisfactory in retrospect. But here we are! > it is a good idea to add another, strict Gregorian (error before 1582). Thanks for seeing it like that. Yes, perhaps we should define what I suggested as a new calendar: strict_gregorian, which is not allowed to have a ref date before 1582, or to use negative time coordinates, or to describe dates before 1582 (which would be impossible given the first two conditions). (Note, I am not personally the eponymous strict Gregory.) In that case, we could change the default in the next release from gregorian or standard to strict_gregorian. For software which is careful about versions, this would mean that dates in the default calendar before 1582 would give an error. This would be a safe failure, rather than a wrong answer. > Some data sets would be CF compliant only under particular versions of CF. > Is this the first time that a change to CF would have such an impact? In the sense of old data becoming invalid in a *later* version, yes I think it is. Of course new features always allow datasets which are invalid in an *earlier* version. In the failing cases, I think we agree that tools might offer the facility > to provide the calendar if none was found. > However, I imagine most tools would continue to assume the current default. Yes, I expect so. They would still be unsafe, if datasets have been wrongly coded with the default, but it would be no worse than now. > This does not seem so bad to me. The removal of the default solution > should not produce the nastier kinds of errors that you would get if > you changed the default. That's what I think, except that formally the above suggestion is a change to to the default - one which installs a fail-safe mechanism. Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
