[Python-Dev] Issue5434: datetime.monthdelta

[Paul Moore]

2009/4/16 Antoine Pitrou <solipsis at pitrou.net>:
> Paul Moore <p.f.moore <at> 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 add_months 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.add_months()" 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.