Dear Bärring, This seems sensible but there always seems to be a gotcha with calendars. The only thing I've learned that I hold to is to avoid reinventing anything when it comes to them.
I would be interested to hear Jon Blower's perspective on this discussion (do you still watch this space, Jon?). He is the source of the logic I outlined that was implemented in the NetCDF-Java CDM. I think the logic implemented there <http://reading-escience-centre.github.io/edal-java/apidocs/uk/ac/rdg/resc/edal/util/chronologies/ThreeSixtyDayChronology.html> is in line with what's being proposed? For a 360 day chronology: > "a year has a fixed number of milliseconds (1000*60*60*24*360)." - Dave > On Oct 18, 2018, at 8:31 AM, Bärring Lars <lars.barr...@smhi.se> wrote: > > Dear Martin, David, all, > > As Klaus points out, the aim of my suggestion is to make software using CF > aware of the fact that the unit "year" is different depending on which > calendar the model is implementing. To give an example: > If I want to know when the global average temperature has increased by 1.5C, > or 4C, above pre-industrial time in the CMIP5 ensemble I will get answers as > a timedelta in days. As this is not really helpful I might feel inclined to > convert this to years, but now UDUNITS definition of year is not helpful for > those models having a 360_day or 365_day calendar. However, with the > calendar-aware definition of year such a calculation would be supported > without having to deal with it manually. > > Now, on to the discussion about months. Before my previous post I quickly > read through extensive exchange on this list back in 2011, so I really > appreciate David's comment that it is a complex subject. And that is the > reason for why I suggested is always month is always a year / 12. So, here is > an attempt to summarise the suggestion in a different way: > > * standard and proleptic_gregorian calendars (status quo): > o the number of days in a month is not an integer > o same issue with respect to ordinary (western) world months. > > * 365_day calendar: > + the number of seconds in a month would change from being "ill-defined > (?)" as 84600 * 365.242198781 / 12 = 2574957.50141, to more properly 84600 * > 365 / 12 = 2573250 > o same issue with respect to ordinary (western) world months. > > * 360_calendar: > + the number of seconds in a month would change from being "very > ill-defined (?)" as 84600 * 365.242198781 / 12 =2574957.50141, to more > properly 84600 * 360 / 12 = 2538000 > + the number of days in a month is an integer; 12 * 30 * 84600 = 2538000 > + the definition of a month is consistent with what is expected in the > "360_day world" > o same issue with respect to ordinary (western) world months. > > That is, even though the suggestion certainly do not solve everything (of > course!), the only argument against it, that I can see, is the work to tease > out the details and implement it in software packages. As was extensively > discussed in the 2011 threads, the real problem is the varying length of the > western world calendar months. But that is the topic for another thread. > > > Kind regards, > Lars > > Från: CF-metadata [cf-metadata-boun...@cgd.ucar.edu > <mailto:cf-metadata-boun...@cgd.ucar.edu>] för David Blodgett > [dblodg...@usgs.gov <mailto:dblodg...@usgs.gov>] > Skickat: den 18 oktober 2018 13:58 > Till: Ryan Abernathey > Kopia: cf-metadata@cgd.ucar.edu > Ämne: Re: [CF-metadata] 'months since' and 'years since' time units > > Dear Ryan, All, > > I hesitate to chime in on this thread as I know just how fraught this topic > can be, but then I think I know how fraught it can be so may have something > to offer. My experience is at the intersection of climatological models and > landscape models that are calibrated with "real" data. I've worked with daily > and monthly time series model output and interpolated weather products that > needs to match up to observations but uses a noleap or 360 calendar. It's an > enormous pain and we as a community should do better. -- so the business case > for taking this complexity head on is there! > > One resource I've found useful over the years is the [CDM > implementation](https://www.unidata.ucar.edu/software/thredds/current/netcdf-java/CDM/CalendarDateTime.html > > <https://www.unidata.ucar.edu/software/thredds/current/netcdf-java/CDM/CalendarDateTime.html>) > > > There are two factors at play. > > 1) Adding "calendar" to a udunits string avoids conversion to a number of > shorter time increments for long time increments (e.g. seconds per month). It > keeps things in the declared time units so you hit the precise date > boundaries you would expect. > 2) The "calendar" attribute gets you to how to interpret the datum of the > time axis. > > Especially relevant to this thread is: > uniform30day or 360_day = All years are 360 days divided into 30 day months. > With these two, I think the problems here are solved. However, inevitably, > people will omit the addition attribute for calendar or fall back on normal > "months since ..." when they actually mean "calendar months since ..." and > tell us 'why would you interpret my data that way it makes no sense?!?' This > is perfectly parallel to spatial coordinates where people don't declare a > datum for their latitude/longidute coordinates. Without that information one > can not use the information with a level of precision that some use cases > require. > > What I'm getting at is that CF should probably: > 1) adopt enough attribute precision to fully describe what we are trying to > convey > 2) make said attributes required or declare sensible defaults that reduce > ambiguity when users come knocking. > > That said, I've had no success pushing the community to accept that there > should be a default lat/lon datum for software developers to go on and I > would not doubt that the same will be true here as ambiguity and uncertainty > is better than dead wrong in many cases. My stance is that we should all be > dead wrong for the same reason rather than each implementor making an > arbitrary decision so we all get different answers (more ambiguity) from our > software du-jour. > > All the best, > > Dave > > >> On Oct 18, 2018, at 6:08 AM, Martin Juckes - UKRI STFC >> <martin.juc...@stfc.ac.uk <mailto:martin.juc...@stfc.ac.uk>> wrote: >> >> Hello All, >> >> >> I think the UNIDATA pull request referenced Jeff >> (https://github.com/Unidata/cftime/pull/69 >> <https://github.com/Unidata/cftime/pull/69>) is mis-quoting the CF >> Convention. As far as I can see, Unidata says that a month is exactly one >> 12th of a year, and CF inherits this -- with the statement "For similar >> reasons the unit month, which is defined in >> udunits.dat<http://www.unidata.ucar.edu/software/udunits/ >> <http://www.unidata.ucar.edu/software/udunits/>> to be exactly year/12, >> should also be used with caution." >> >> >> I can't see the difference between Lars's suggestion and the status quo. In >> UNIDATA a day is clearly defined as "period of time equal to 24 hours", >> which gives 84600 seconds. >> >> regards, >> Martin >> >> >> >> ________________________________ >> From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu >> <mailto:cf-metadata-boun...@cgd.ucar.edu>> on behalf of Bärring Lars >> <lars.barr...@smhi.se <mailto:lars.barr...@smhi.se>> >> Sent: 18 October 2018 09:29:50 >> To: Ryan Abernathey; whitaker.jeff...@gmail.com >> <mailto:whitaker.jeff...@gmail.com>; cf-metadata@cgd.ucar.edu >> <mailto:cf-metadata@cgd.ucar.edu> >> Subject: Re: [CF-metadata] 'months since' and 'years since' time units >> >> Hi, >> >> I have have come to think about this from a somewhat different perspective. >> For some analyses, as well as when calculating certain derived >> climatological statistics (aka climate indices), using datasets based on >> different calendars the problem becomes obvious. >> >> In the model world of a 365-day GCM one year _is_ 365 days, and in a 360_day >> GCM a year _is_ 360 days. In the case of a gregorian/standard calendar GCM I >> am not sure whether it is 365.25 or 365.242198781 but this is in practice >> less of a problem. >> >> For datasets based non-standard calendars imposing the current UDUNITS >> definition of a year leads to complications that require workarounds if one >> is interested in for example the time elapsed until something happens or the >> duration of some (long-lasting) events. One way to partly mitigate these >> issues would be to use the time unit of years_since_START or >> months_since_START, but this is warned against in the CF Conventions and may >> software tools do not support it . >> >> The fundamental issue is the inconsistency between the GCM year and the >> UDUNITS year. So I would like to call on the wisdom of this list to see >> whether the CF Convention could include a modification to the definition of >> a year and month: >> >> * standard calendar (no change) >> 1 day = 84600 seconds >> 1 year = 365.242198781 days >> 1 month = 365.242198781 / 12 days >> >> * 365_day calendar >> 1 day = 84600 seconds >> 1 year = 365 days >> 1 month = 365 / 12 days >> >> * 360_day calendar >> 1 day = 84600 seconds >> 1 year = 360 days >> 1 month = 360 / 12 days >> >> That is, the seconds per day ratio is not changed thus maintaining the >> consistency to other SI units. And, for the 360_day calendar month follows >> the suggestion by Ryan and Jeffrey. >> >> >> Kind regards, >> Lars >> >> -- >> Lars Bärring >> >> FDr, Forskare >> PhD, Research Scientist >> >> SMHI / Swedish Meteorological and Hydrological Institute >> Rossby Centre >> SE - 601 76 NORRKÖPING >> Tel / Phone: +46 (0)11 495 8604 >> Fax: +46 (0)11 495 8001 >> Besöksadress / Visiting address: Folkborgsvägen 17 >> ________________________________ >> Från: CF-metadata [cf-metadata-boun...@cgd.ucar.edu >> <mailto:cf-metadata-boun...@cgd.ucar.edu>] för Ryan Abernathey >> [ryan.abernat...@gmail.com <mailto:ryan.abernat...@gmail.com>] >> Skickat: den 17 oktober 2018 21:22 >> Till: whitaker.jeff...@gmail.com <mailto:whitaker.jeff...@gmail.com> >> Kopia: cf-metadata@cgd.ucar.edu <mailto:cf-metadata@cgd.ucar.edu> >> Ämne: Re: [CF-metadata] 'months since' and 'years since' time units >> >> Hi everyone, >> >> I am that user, and I'm new to this mailing list. Thank you all for your >> work on CF conventions. It's such a valuable effort! >> >> I want to note that this was inspired by the proliferation of datasets in >> the wild that use "month" as their units. For example, nearly all of the IRI >> Data Library does this, in conjunction with a 3"60_day" calendar (example: >> https://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCEP-NCAR/.CDAS-1/.MONTHLY/.Diagnostic/.surface/.temp/ >> >> <https://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCEP-NCAR/.CDAS-1/.MONTHLY/.Diagnostic/.surface/.temp/>). >> >> My impression from talking to data providers is that no one is using >> "360_day" calendar and "months" as units, and then expecting "months" to be >> interpreted as 365.242198781/12 days. They all expect it to be interpreted >> as 30 days. While there are various workarounds that can be used at >> different levels of the software stack, the best solution, IMHO, is to >> explicitly allow in CF conventions what Jeff proposed: "months and years be >> interpreted as calendar months and years for those calendars where they have >> a fixed length". I don't think this will break existing applications. >> >> Thanks, >> Ryan >> >> On Wed, Oct 17, 2018 at 3:06 PM Jeffrey Whitaker <whitaker.jeff...@gmail.com >> <mailto:whitaker.jeff...@gmail.com><mailto:whitaker.jeff...@gmail.com >> <mailto:whitaker.jeff...@gmail.com>>> wrote: >> Hi: I'm a developer of the 'cftime' python package >> (https://github.com/Unidata/cftime <https://github.com/Unidata/cftime>). A >> user submitted a pull request (https://github.com/Unidata/cftime/pull/69 >> <https://github.com/Unidata/cftime/pull/69>) that implements support for a >> 30-day calendar month time unit for the '360_day' CF calendar. Although >> using a 'month' time unit is a tricky proposition in general, for this >> calendar it seems straightforward since every month has the same length. >> However, in the discussion of the pull request it was pointed out that CF >> expects that "the value of the units attribute is a string that can be >> recognized by UNIDATA’s Udunits package", and that UDUNITS defines a month >> as 365.242198781/12 days. My question is this - is it reasonable for our >> python package to make an exception to this rule for the 360_day calendar? >> More generally, can months and years be interpreted as calendar months and >> years for those calendars where they have a fixed length, or will this >> deviate from the existing CF conventions and break existing applications? >> >> Regards, Jeff >> >> -- >> Jeffrey S. Whitaker >> NOAA/OAR/PSD R/PSD1 >> 325 Broadway, Boulder, CO, 80305-3328 >> Phone: (303)497-6313 >> FAX: (303)497-6449 >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata@cgd.ucar.edu >> <mailto:CF-metadata@cgd.ucar.edu><mailto:CF-metadata@cgd.ucar.edu >> <mailto:CF-metadata@cgd.ucar.edu>> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> <http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata@cgd.ucar.edu <mailto:CF-metadata@cgd.ucar.edu> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> <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
