# [Python-Dev] dateutil

Gustavo Niemeyer niemeyer at conectiva.com
Mon Mar 15 09:56:32 EST 2004

```> > I'll try to answer your doubts here, and later I'll review the
> > documentation again trying to explain these issues in a better,
> > non-ambiguous way.
>
> There's no need to reply to me at all <wink>.  It does suggest that if
> you want to fold it into the core, a PEP is really in order.  The
> usual way

Understood, and agreed.

> things go is that you get no feedback at all until *someone* asks
> questions in public.  That gets other people thinking about it too,
> and then the floodgates open.  For example, I see Greg Ewing already
> took the bait, and has his own set of design questions.  While I'm
> sure the bulk of the questions I asked have clear and
> non-controversial answers, some of the decisions are debatable.

Ok..

[...]
> I assume that if d had been date(2000, 1, 31) instead, we would have wound
> up with date(2001, 1, 29), so that adding relativedelta(months=+12) is the
> same as adding relativedelta(years=+1), but neither is necessarily the
> same as adding relativedelta(months=+1) 12 times.  That's defensible,
> it's just not obvious either way.

That's why it's "relative" after all, but I understand your concern.

> > So a relativedelta can affect things in a way that's not
> > relative at all? That sounds *very* confusing.

Yes, it's still relative:

>>> date(2000, 1, 30)+relativedelta(day=31)
datetime.date(2000, 1, 31)
>>> date(2000, 1, 20)+relativedelta(day=31)
datetime.date(2000, 1, 31)
>>> date(2000, 2, 20)+relativedelta(day=31)
datetime.date(2000, 2, 29)

> > Wouldn't it be better if relativedelta confined itself to
> > relative things only, and provide some other way of
> > absolutely setting fields of a date?
>
> I'm sure this part was inherited from mxDateTime.  I find it confusing to

Yes, the idea is based on mxDateTime, but notice that the behavior is
not the same. They're two different implementations using different
concepts. For example:

>>> DateTime.DateTime(2000,2,1)+DateTime.RelativeDateTime(day=31)
<DateTime object for '2000-03-02 00:00:00.00' at 40588368>

>>> date(2000,2,1)+relativedelta(day=31)
datetime.date(2000, 2, 29)

> slam so much mixed functionality into a single type.  The Python

I don't think it's mixed, but it's my biased opinion of course.

> datetime types support .replace() methods already for replacing fields
> with absolute values, although they complain if an out-of-range
> replacement is attempted; e.g.,

Exactly.

[...]
> This makes operations like "move to the end of the current month"
> non-trivial (not *hard*, just non-trivial).  I'm not sure they're
> trivial in Gustavo's scheme either, though.  Java supports distinct
> notions of "set",

Yes, it's easy:

d + relativedelta(day=31)

We might even get some constants like:

end_of_month = relativedelta(day=31)

So that one might do "d+end_of_month".

> "add" and "roll" to cater to different use cases, and a discussion of that
> would be great to see in a PEP:
>
>     http://java.sun.com/j2se/1.3/docs/api/java/util/Calendar.html
>
> I'll confess in advance that I can't make sense of them either <wink>.

"""
Example: Consider a GregorianCalendar originally set to August 31, 1999.
Calling roll(Calendar.MONTH, 8) sets the calendar to April 30, 1999. Add
rule 1 sets the MONTH field to April. Using a GregorianCalendar, the
DAY_OF_MONTH cannot be 31 in the month April. Add rule 2 sets it to the
closest possible value, 30. Finally, the roll rule maintains the YEAR
field value of 1999.
"""

I'm still trying to understand why this is useful. By the comment below
this one, it looks like it's something for GUI interaction.

--
Gustavo Niemeyer
http://niemeyer.net

```

More information about the Python-Dev mailing list