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>
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
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20181017/daf2fab8/attachment.html>
Received on Wed Oct 17 2018 - 13:22:54 BST
