Re^6: Finding End of Month's date

Trying on for size is a figure or speech for “now see how that looks”. I never golf.

Also, please look at a module before decrying it for inflexibility.

print $date->strftime( '%e' ); # it's there if you think you need it
[download]

By truncation I was referring the fact that the calculation starts at the beginning of the month rather than from “now”. Without your explanation, I'd've expected your snippet to produce June 15 when given May 16 as a start date. It's not obvious why it produces May 31 instead.

Or did you think the well known formula that checks the remainers of division of the year by 4, 100 and 400 got the edge cases right? ;-)

I know it doesn't, no need for the smiley. That's why I asked the question in the first place. I'd never attempt to do any date math on my own unless I'm setting out to write a date math library. Otherwise, there's just way too many gotchas to hang yourself with in that area. And when I pick a date math library, I usually stick to DateTime because I know there was (and is) a large and painstaking effort to get every last possible edge case right, and because the API is terrifically slick.

Makeshifts last the longest.

Comment on Re^6: Finding End of Month's date Download Code

Replies are listed 'Best First'.
Re^7: Finding End of Month's date by Anonymous Monk on Jan 04, 2005 at 09:36 UTC
I'd've expected your snippet to produce June 15 when given May 16 as a start date. It's not obvious why it produces May 31 instead. Actually, if you give it "May 16" as arguments, it will produce 31 as the answer. Why? Because the original question stated the problem as given a month and a year. So, my snippet takes a month and a year, and hence "May 16" will be the month of May in the year 16. And if you give ParseDate incomplete dates, it assumes defaults. Like oh, the first second (00), the first minute (00), the first hour (00) and the first day (1). Exactly what I expect. BTW, Date::Time uses the same defaults. and because the API is terrifically slick Oh, the irony. The irony. The API specially allows chaining mutators - and your example makes use of them.	[reply]
Re^8: Finding End of Month's date by Aristotle (Chancellor) on Jan 04, 2005 at 19:09 UTC
Use call_on_obj() and don't chain. It's still a slick API, Q.E.D. FWIW, DateTime IMHO falls under the accumulator exception, just like the chained calls in File::Find::Rule. Makeshifts last the longest.	[reply]
Re^9: Finding End of Month's date by Anonymous Monk on Jan 05, 2005 at 10:48 UTC
Use call_on_obj() and don't chain. Why should I? You were the person who complained about chaining mutators, and you were the one that used them in preference over `call_on_obj`. I don't object to the use of chaining mutators. Q.E.D. Eh? What were you supposed to prove, and how did your prove it? FWIW, DateTime IMHO falls under the accumulator exception, `$obj -> truncate(to => 'month') -> add('months' => 1, days => -1)` is an "accumulator exception" (guess 'truncate' and 'add' are "accumulators" then), but `$widget -> title(foo) -> border(20)` isn't? That makes me curious. What decides whether something falls under "accumulator exception" and what doesn't?	[reply]