Full support for UDUNIT years units

[kmpaul]

@jhamman Hope all is well with you since the AOSPy Workshop! I'm putting an issue in here to address some missing capabilities that are CF compliant, but not fully supported by the netcdftime module.

This issue can be immediately seen by trying to initialize a utime instance with the 'common_year' or 'year' units (which are UDUNITS supported):

utime('common_years since 1-1-1 0:0:0, calendar='noleap')

which immediately errors with the error:

ValueError: units must be one of 'seconds', 'minutes', 'hours' or 'days' (or singular version of these), got 'years'

My understanding is that this should work, since 'common_year' is a fixed multiple of 'day' (i.e., 365 days, regardless of calendar). However, netcdftime does not support any year-like units.

I'm interested in implementing this ASAP, so I might fork the repo and put in a PR soon-ish.

[jhamman]

@kmpaul, I don't have any objection to that change but I'll let others (@jswhit) weigh in as well.

As far as where netcdftime is at in terms of being ready for other contributions, it should be ready. The travis tests are passing although there are still a few issues to work through before we can swap the module out for the one in netCDF4.

[jswhit]

Sounds like common_years since 1-1-1 0:0:0, calendar='noleap' should be the same as years since 1-1-1 0:0:0, calendar='365_day' or years since 1-1-1 0:0:0, calendar='noleap'. Sounds reasonable to make common_years since a synonym for either of those two. An error should be raised if an inconsistent calendar is specified though.

[kmpaul]

Yeah. That's exactly what I was thinking, but I wanted to research this a bit more before implementing a change.

…

On Thu, Dec 29, 2016 at 11:45 AM, Jeff Whitaker ***@***.***> wrote: Sounds like common_years since 1-1-1 0:0:0, calendar='noleap' should be the same as years since 1-1-1 0:0:0, calendar='365_day' or years since 1-1-1 0:0:0, calendar='noleap'. Sounds reasonable to make common_years since a synonym for either of those two. An error should be raised if an inconsistent calendar is specified though. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AK4fg_Bko5oXG05I8PUmS908kr3rRW24ks5rM__XgaJpZM4LAyT3> .

-- *Kevin Paul, PhD* Project Scientist, Head of I/O & Workflow Applications (IOWA) The National Center for Atmospheric Research Computational and Information Systems Laboratory 1850 Table Mesa Dr Boulder, CO 80305 Phone: (303) 497-2441 Office: ML460B

[jswhit]

@kmpaul - is a pull request coming for this?

[kmpaul]

Time and schedule as they are, I can’t do this. Sorry.

[jswhit]

OK, I'll leave this open in case someone wants to tackle it.

[jswhit]

Closed by PR #246