Allow user to specify analysis period as a range of dates, rather than years about aospy HOT 5 CLOSED

This is in general a solid solution.

In fact, it seems superfluous to have both _yr and _date variants of these kwargs. So I am inclined to replace the former with the latter, i.e. the kwargs would be nc_start_date, nc_end_date, and default_time_range. If passed an integer, a datetime object (of the netCDF4 variety; see below) is generated assuming January 1 of that year.

Re: which datetime object to use, it seems to me that netCDF4.netcdftime.datetime is the way to go, given the year 0001, etc. considerations. Doesn't add any new dependencies and resolves that problem. Good find!

This would not be backwards compatible: you and I (confidently assuming we are still the only users) would have to change these in the objects we have already. But I think it's worth the trouble -- shouldn't worry about legacy code at this early, volatile stage of the project.

from aospy.

As of the most recent commit to the xray branch (3ebb63f), this has been implemented, in that _yr kwargs/attributes have been replaced with _date variants, with datetime.datetime objects being used primarily rather than integers corresponding to years. The TimeManager class and timedate module have been added to handle time- and date-related computations.

However, I have not yet tested it yet for non-vanilla times, i.e. years < 1678 or not spanning full months/years. So not quite ready to close the issue yet, not until we write some tests that demonstrate the new stuff actually works for all of our use cases.

from aospy.

Yes, I've just tested a case under the xray branch with years < 1678; there are some bugs. Once I get things sorted out I'll create a pull-request.

from aospy.

@spencerkclark Does the code you implemented in the above pull request fix the bugs you came across? If yes, I'll close this issue.

from aospy.

Yes, the code I implemented fixes the issues I was having. I'll go ahead and close it.

from aospy.