Re^7: Finding End of Month's date

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.

Comment on Re^7: Finding End of Month's date

Replies are listed 'Best First'.
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]