Gustavo Niemeyer wrote: >>>>> 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. >>> >>> >>Hmm, I feel vaguely uncomfortable actually relying on the "round down out >>of range values" behaviour. Presumably day=1000 would also work, and would >>look even stranger to me :-) >> >> > >This was a design decision, and I confess I'm pretty satisfied >by the results of this decision. This simple decision created >consistent and expectable results for operations which are not >obvious. Also, without this feature, I see almost no reason for >using this class instead of timedelta. > > The alternative way to getting the end of the month (which I used in my datetime class) was to perform two adjustments: >> end_of_month = date.adjust_absolute(day=1).adjust_relative(month=+1,day=-1) This requires that the relative adjustments are applied in order from most significant adjustment to least. Now that I've seen the Gustavo's semantics, I think his may be more sensible (even though the particular gymnastics where hidden behind a helper- method, so that most developers never had to know these subtleties). -Kevin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4