Dear Martin The definition of a calendar_month unit would also need rules about calendar arithmetic e.g. What does 1 calendar_month since 31 January mean? What does 7.23 calendar_months since 31 January mean?
Best wishes Jonathan ----- Forwarded message from Martin Juckes - UKRI STFC <[email protected]> ----- > Date: Thu, 18 Oct 2018 16:33:28 +0000 > From: Martin Juckes - UKRI STFC <[email protected]> > To: Jonathan Gregory <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [CF-metadata] 'months since' and 'years since' time units > > Dear Jonathan, > > > I think you could go further and disallow the use of "month" or "year" as a > time unit when the calendar is not standard. > > > If the "ncdump -t" option produces what the user expects when he has units > "months since 1900-01-01" and a 360 day calendar, then it is going to be > inconsistent with the current convention. > > > I still feel that there is an argument for enabling the storage of > information in user months in the files. E.g. I wish to compare monthly mean > data from 20 climate models which use a range of different calendars. The > mean across the models is not on any specific calendar ... I could pretend it > is and use units of "days since ...", but the mappings from input time > coordinates to output time coordinates then become rather complex, when they > should be trivial. Having a "date" standard name which allowed the input data > to have a "calendar_month" coordinate would solve this (and I think Klaus's > suggestion would also solve it), > > > regards, > > Martin > > ________________________________ > From: CF-metadata <[email protected]> on behalf of Jonathan > Gregory <[email protected]> > Sent: 18 October 2018 17:10:46 > To: [email protected] > Subject: Re: [CF-metadata] 'months since' and 'years since' time units > > Dear all > > This is an interesting discussion, and I agree that's a tricky subject. If > only > we could have a well-behaved Earth which orbited the sun in an integral and > easily factorisable number of days! > > So far I still think that we should not change the way we interpret the units > string. It's in udunits format, and should be interpreted according to the > calendar attribute. I would suggest that it's helpful to regard time coords as > *encoded* and not necessarily easy for humans to read. It's certainly nice to > see "time=1, 2, 3, ..." months since a reference date - that is easy to read - > but when you get to 747 or 4689 months since a reference date, you don't know > what it means any more (unless you're extremely good at mental arithmetic), > and > you might as well encode it as days. > > The antidote to inconvenient encoding is convenient software. For example, > could cftime allow the user to construct a time coordinate variable with a > spacing of calendar months, but encode it in the netCDF file in days? Then > it's > transparent. Similarly, time coordinate variables can be decoded into human- > readable strings by calendar-aware software. It seems to me that this isn't > different in principle from using ncdump to read a netCDF file, rather than > insisting it should be intelligible when read in hexadecimal. In fact, ncdump > itself has a -t option, which should help, according to the man page: > > "-t controls display of time data, if stored in a variable that uses a udunits > compliant time representation such as `days since 1970-01-01' or `seconds > since > 2009-03-15 12:01:17' .... If this option is specified, time data values are > displayed as human-readable date-time strings rather than numerical values, > interpreted in terms of a `calendar' variable attribute, if specified. ... > Calendar attribute values interpreted with this option include the CF > Conventions values `gregorian' or `standard', `proleptic_gregorian', `noleap' > or `365_day', `all_leap' or `366_day', `360_day', and `julian'." > > I agree with comments that if we introduced new units such as calendar_month > or 30day_month, people might well not use them, and would still be > disappointed > that "month" wasn't what they expected. > > The CF conformance document has a recommendation that "year" and "month" > should > be used "with caution". I don't what the CF checker currently does with this. > We could change it to a recommendation that they should *not* be used, in > which > case the checker would give a warning if they were. > > Best wishes > > Jonathan > > ----- Forwarded message from Bärring Lars <[email protected]> ----- > > > Date: Thu, 18 Oct 2018 13:31:10 +0000 > > From: Bärring Lars <[email protected]> > > To: Martin Juckes - UKRI STFC <[email protected]>, David Blodgett > > <[email protected]>, Ryan Abernathey <[email protected]> > > Cc: "[email protected]" <[email protected]> > > Subject: Re: [CF-metadata] 'months since' and 'years since' time units > > > > 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 [[email protected]] för David Blodgett > > [[email protected]] > > Skickat: den 18 oktober 2018 13:58 > > Till: Ryan Abernathey > > Kopia: [email protected] > > Ä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) > > > > 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 > > <[email protected]<mailto:[email protected]>> wrote: > > > > Hello All, > > > > > > I think the UNIDATA pull request referenced Jeff > > (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/> 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 > > <[email protected]<mailto:[email protected]>> > > on behalf of Bärring Lars > > <[email protected]<mailto:[email protected]>> > > Sent: 18 October 2018 09:29:50 > > To: Ryan Abernathey; > > [email protected]<mailto:[email protected]>; > > [email protected]<mailto:[email protected]> > > 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 > > [[email protected]<mailto:[email protected]>] > > för Ryan Abernathey > > [[email protected]<mailto:[email protected]>] > > Skickat: den 17 oktober 2018 21:22 > > Till: [email protected]<mailto:[email protected]> > > Kopia: [email protected]<mailto:[email protected]> > > Ä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/). > > > > 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 > > <[email protected]<mailto:[email protected]><mailto:[email protected]>> > > wrote: > > Hi: I'm a developer of the 'cftime' python package > > (https://github.com/Unidata/cftime). A user submitted a pull request > > (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 > > [email protected]<mailto:[email protected]><mailto:[email protected]> > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > _______________________________________________ > > CF-metadata mailing list > > [email protected]<mailto:[email protected]> > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > _______________________________________________ > > CF-metadata mailing list > > [email protected] > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > ----- End forwarded message ----- > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
