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-bounces at cgd.ucar.edu> on behalf of Ryan Abernathey <ryan.abernathey at gmail.com>
Sent: 17 October 2018 20:22
To: whitaker.jeffrey at gmail.com
Cc: cf-metadata at 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.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
________________________________
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.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20181018/ef7bbf8e/attachment.html>
Received on Thu Oct 18 2018 - 02:09:04 BST
