Hello All,
On 18/10/18 13:08, Martin Juckes - UKRI STFC 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.
The difference is merely that 'year' is defined as an alias for
'tropical_year' and is always 365.24219878125 days, regardless of
calendar. Lars suggestion could be implemented by introducing new units
along the lines of 'julian_month', 'gregorian_month', 'sidereal_month', etc.
Indeed, for the 360 day calendar, this would lead exactly to Roy's
suggestion with '30_day_month' as a new unit allowing one to write
'30_day_month since ...'.
Also Ryan is correct that basically any human reading the month units
will understand them in the same way; I even think this holds generally
for all calendars. The problems will come from software where packages
will use the generic udunits api to convert these times to seconds or
hours, for example to determine frequencies, or simply to the same
calendar to homogenize data from different sources.
Hence, I don't think this approach is a good idea: The fact is, months
and years just don't fit very well in the whole units framework. They
are unique in that there is no simple relation given by scale factor and
offset with other time units. Just to stress this point: In all units
from albedo to yard you can perform the conversion to a different unit
for the same quantity independent from the value of the quantity. For
years and months it depends on intimate knowledge of the calendar and on
the date in question. Therefore, as the cf convention already states,
months and years really shouldn't be used as units for the time axis;
rather 'days since ...' together with a calendar in the attributes are
the best option at the moment. Together with a package like calcalcs[1],
this allows for relatively straightforward conversion to/from a (YYYY,
MM, dd) triple.
Of course, on the other hand as Jeff noted, months are exceedingly
popular as a unit and with good reason. But perhaps we could borrow from
packages like iris[2] here and add an additional auxiliary coordinate
'month_number' to the specification to help with the practical needs?
Cheers
Klaus
[1]
http://meteora.ucsd.edu/~pierce/calcalcs/index.html
[2]
https://scitools.org.uk/iris/docs/latest/iris/iris/coord_categorisation.html#iris.coord_categorisation.add_month_number
>
> regards,
> Martin
>
>
>
> ________________________________
> From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of B?rring Lars <Lars.Barring at smhi.se>
> Sent: 18 October 2018 09:29:50
> To: Ryan Abernathey; whitaker.jeffrey at gmail.com; cf-metadata at 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-bounces at cgd.ucar.edu] f?r Ryan Abernathey [ryan.abernathey at gmail.com]
> Skickat: den 17 oktober 2018 21:22
> Till: whitaker.jeffrey at gmail.com
> Kopia: cf-metadata at 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/).
>
> 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.jeffrey at gmail.com<mailto:whitaker.jeffrey at gmail.com>> 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
> CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Thu Oct 18 2018 - 05:38:24 BST
