[Python-Dev] Python-Dev Digest, Vol 69, Issue 143

[Jess Austin]

Jared Grubb <jared.grubb at gmail.com> wrote:
> On 16 Apr 2009, at 11:42, Paul Moore wrote:
>> The key thing missing (I believe) from dateutil is any equivalent of
>> monthmod.
>
>
> I agree with that. It's well-defined and it makes a lot of sense. +1
>
> But, I dont think monthdelta can be made to work... what should the
> following be?

>>> print(date(2008,1,30) + monthdelta(1))
2008-02-29
>>> print(date(2008,1,30) + monthdelta(2))
2008-03-30
>>> print(date(2008,1,30) + monthdelta(1) + monthdelta(1))
2008-03-29

This is a perceptive observation: in the absence of parentheses to
dictate a different order of operations, the third quantity will
differ from the second.  Furthermore, this won't _always_ be true,
just for dates near the end of the month, which is nonintuitive.
(Incidentally, this is another reason why this functionality should
not just be lumped into timedelta; guarantees that have long existed
for operations with timedelta would no longer hold if it tried to deal
with months.)

I find that date calculations involving months involve a certain
amount of inherent confusion.  I've tried to reduce this by
introducing well-specified functionality that will allow accurate
reasoning, as part of the core's included batteries.  I think that one
who uses these objects will develop an intuition and write accurate
code quickly.  It is nonintuitive that order of operation matters for
addition of months, just as it matters for subtraction and division of
all objects, but with the right tools we can deal with this.  An
interesting consequence is that if I want to determine if date b is
more than a month after date a, sometimes I should use:

    b - monthdelta(1) > a

rather than

    a + monthdelta(1) < b

[Consider a list of run dates for a process that should run the last
day of every month: "a" might be date(2008, 2, 29) while "b" is
date(2008, 3, 31). In this case the two expressions would have
different values.]

cheers,
Jess