Dear Jeff,
I see a possibility for confusion here. Whilst the meaning of 'month' as 30 days is well understood within the 360-day calendar community, others from outside that community could easily use 'months since' expecting it to mean 365.242198781/12. Would it be possible to use a more explicit label like '30 day months since'? I appreciate when suggesting this that I'm not aware of the history of 'months since' in UDUNITS and have no idea how deeply embedded it is out in the wild and therefore of its consequences. Cheers, Roy. I have now retired but will continue to be active through an Emeritus Fellowship using this e-mail address. ________________________________ From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Ryan Abernathey <ryan.abernat...@gmail.com> Sent: 17 October 2018 20:22 To: whitaker.jeff...@gmail.com Cc: cf-metadata@cgd.ucar.edu Subject: 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/). data: NOAA NCEP-NCAR CDAS-1 MONTHLY Diagnostic surface temp <https://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCEP-NCAR/.CDAS-1/.MONTHLY/.Diagnostic/.surface/.temp/> iridl.ldeo.columbia.edu MONTHLY Diagnostic surface Temperature from NOAA NCEP-NCAR CDAS-1: Climate Data Assimilation System I; NCEP-NCAR Reanalysis Project. Resolution: 1.875x1.904128; Longitude: global; Latitude: global; Time: [Jan 1949,Sep 2018]; monthly 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>> 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@cgd.ucar.edu<mailto:CF-metadata@cgd.ucar.edu> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ________________________________
_______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
