[Python-Dev] dateutil

[Gustavo Niemeyer]

> >  d.forward_months(3).end_of_month()
> 
> In dateutil, I think it's d + relativedelta(months=+1, day=1, days=-1).
> Arguably, this is fairly trivial (highly non-obvious, but trivial...)

Yes, it'd work, but "d + relativedelta(day=31)" would be enough.

> It's a trade-off, power at the cost of comprehensibility. I've always
> been a fan of flexible, powerful tools (and I'm sure the readability of
> my code suffers for it :-)). So I prefer relativedelta.

Thanks! I belive it'd also be easy to implement the interface mentioned
by Greg on top of relativedelta.

> Some use cases that I find hard with "bare" datetime (all are real
> requirements for me):
> 
> 1. For a date d, get the start and end of the month containing it.
>    (many "report this month" jobs)

(just as examples)

d + relativedelta(day=1)
d + relativedelta(day=31)

> 2. For a date d, get the start and end of the month before it.
>    (equivalent "report last month" jobs). This is just (1) plus the
>    need to subtract "roughly" a month from a date.

d + relativedelta(months=-1, day=1)
d + relativedelta(months=-1, day=31)

> 3. 12 noon on the first Thursday of next month. (Don't blame me, that's
>    when we have a maintenance slot on one of our systems).

d + relativedelta(months=+1, day=1, weekday=TH, hour=12)

> 4. The last Friday of the month. (End-of-month reporting time).

d + relativedelta(day=31, weekday=FR(-1))

> The key functionality here is "add N months" and "go to weekday N
> (forward or backward)". Both things that the core datetime avoids for
> well-explained reasons.

Agreed.

> I'm happy with dateutil as it stands, outside of the core. If it's to
> go into the core, I agree that a PEP would be the right thing to do.
> And probably not just one - separate PEPS for the different areas would
> focus discussion better:
[...]

Understood. Thanks for your comments.

-- 
Gustavo Niemeyer
http://niemeyer.net