Leader of Birmingham.pm [pm.org] and a CPAN author [cpan.org]. Co-organised YAPC::Europe in 2006 and the 2009 QA Hackathon, responsible for the YAPC Conference Surveys [yapc-surveys.org] and the QA Hackathon [qa-hackathon.org] websites. Also the current caretaker for the CPAN Testers websites and data stores.
If you really want to find out more, buy me a Guinness
Links:
Memoirs of a Roadie [missbarbell.co.uk]
[pm.org]
CPAN Testers Reports [cpantesters.org]
YAPC Conference Surveys [yapc-surveys.org]
QA Hackathon [qa-hackathon.org]
Why?
It appears as of DateTime-0.18 a decision has been made to completely scrap the previous implementation of delta_days() and rendered anything that previously used it completely broken.
Previously delta_days() returned the complete number of days between two dates, ie 13th September 1965 to 24th March 1974 is 3845 days, however delta_days() now returns 11 days!
I now have to rewrite my whole damn module just because I depended on that one facet of DateTime. I really wish people would think before the steamrollering an idea through. I made great efforts to get my module compatible with DateTime, and not have to rewrite the world, only to have it thrown back in my face.
I wonder how many more modules (on or off CPAN) that are timebombs waiting to happen?
Update: I was extremely frustrated when I wrote the above. There have been some points raised as to why I shouldn't have written what did. But they were my thoughts at the time. Thank you to echo for helping me put things in perspective.
Sorry, but ... (Score:2)
So while I'm all for backwards compatibility,
Re:Sorry, but ... (Score:2)
Mine are even more explicit. Here's one from WWW::Mechanize [cpan.org]:
--
xoa
Re:Sorry, but ... (Score:2)
It has been really annoying because it now means if anyone updates DateTime and is using my module, or any other module that relies on delta_days(), the code now breaks disastrously. It would have been better to leave the function as is, and create another function along the lines of del
11 (Score:2)
I can't reproduce whatever bug you think you've found. I did this:
print DateTime->new(day=>6,month=>11,year=>2003)->datetime;
and it works fine.
Re:11 (Score:2)
Sad to think that people might be satisfied with complaining than with solving the problem.
--
xoa
Re:11 (Score:1)
Patches for humanity welcome. (Not that I have the maintainer's e-mail address :)
Re:11 (Score:2)
Does it really come down to the level of slashdot comments?
Re:11 (Score:1)
I certainly didn't mean to hurt your feelings and I apologize.
Bug reports for this module are between you and Dave; I have no stake in the matter. I'm just trying to be witty. Sometimes it doesn't work for the intended audience, and that's fine.
Re:11 (Score:2)
If my contributions are so lowly thought of I'll not bother to help in future.
Re:11 (Score:2)
Sorry, let me rephrases: "Sad to think that could be an expectation." I didn't mean it as a putdown.
--
xoa
Re:11 (Score:2)
I have no idea why a month of 11 is failing but it is. I was testing it on Windows so it may be some perculiarity there. I will look more in depth tomorrow.
Whining is for someone who can't be arsed to try and help fix things. You have me mistaken for someone else. If you would like me to take the time in future to try
Re:11 (Score:2)
A month of 11 being a problem mystifies me, since it works fine for me. I'm not sure why it'd be a problem on Windows. But you certainly didn't mention that in the RT report, or I would have responded to it.
As to the infinite t
Re:11 (Score:2)
The infinite issue is not something I've had time to look into. My first assumption was that so
DateTime (Score:1)
Re:DateTime (Score:2)
A fair point.
Seeing as I was testing against the current version that installed on Windows and the same version on my Linux box, I wasn't aware of the change. I will try to be a bit more careful in future.