[Python-Dev] Issue5434: datetime.monthdelta (original) (raw)

Paul Moore p.f.moore at gmail.com
Thu Apr 16 20:31:36 CEST 2009

2009/4/16 Antoine Pitrou <solipsis at pitrou.net>:

Paul Moore <p.f.moore gmail.com> writes:

Oh, certainly! But in the absence of "intuitive", I've found in the past that "standardised" is often better than nothing  (For example, I use Oracle's addmonths function fairly often - it's not perfect, and not always intuitive, but at least it's well-defined in the corner cases, and fine for "normal" use). I think something like "date.addmonths()" would be better than the proposed monthdelta. The monthdelta proposal suggests that addition is something well-defined and rigourous, which is not really the case here (for example, if you add a monthdelta and then substract it again, I'm not sure you always get back the original date).

I didn't particularly get that impression, but I understand what you're saying. Personally, I don't think it matters much one way or the other.

But as well as monthdelta, the proposal included monthmod. I'm not entirely happy with the name, but I like the idea - and particularly the invariant dt + monthmod(dt, dt+td)[0] + monthmod(dt, dt+td)[1] == dt + td. For me, that makes it a lot easier to reason about month increments.

One thing I have certainly needed in the past is a robust way of converting a difference between two dates into "natural language" - 3 years, 2 months, 1 week and 5 days (or whatever). For that type of application, monthmod would have been invaluable.

In my view, monthdelta seems a lot more natural alongside monthmod, than an add_months method would. And as monthmod is a function of two dates, it can't really be a method (OK, I know, something horrid like date1.monthdiff(date2) is possible, but honestly, I don't see that as reasonable).

But this type of API design discussion does emphasise why I think the module should be a 3rd party package for a while before going into the stdlib.

Paul.

More information about the Python-Dev mailing list