[Python-Dev] dateutil
Gustavo Niemeyer
niemeyer at conectiva.com
Mon Mar 15 09:14:17 EST 2004
> > 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
More information about the Python-Dev
mailing list