I uploaded a revamp of all my modules to CPAN this morning. This afternoon one, Calendar-List, has been getting several CPAN Testing errors.
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.
Re:Sorry, but ...
petdance on 2003-11-06T19:36:34
the big section in the change log labelled BACKWARDS INCOMPATIBILITIESMine are even more explicit. Here's one from WWW::Mechanize:
0.62 October 7, 2003 8:46pm
[THINGS THAT MIGHT BREAK YOUR CODE]
* The parms for find_link()'s url_regex and text_regex must now
be actual regex objects, as in qr// objects. They can't just
be little text strings. If this is a big bummer, let me know.Re:Sorry, but ...
barbie on 2003-11-07T00:25:22
The problem is that I'm not interested in the number of seconds, but the actual days. I understand that in some cases days are slightly longer/shorter, but in terms of actual days, how long a day is immaterial for my uses.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 delta_days_accurate(). Then document the reason why not to use delta_days() if you require an exact calculation.
My quick fix is to now disable the use of DateTime if after version 0.16. That's not something I like to do, but I don't have time to add in all the code that I'll need to do the calculation myself.
I didn't notice the "BACKWARDS INCOMPATIBILITIES" section, because I've been using 0.13. It's only because all the test reports were coming back with bizarre errors that I took the time to shoehorn v0.18 into installing (the infinity thing is a bit of bugger!).
print DateTime->new(day=>6,month=>11,year=>2003)->datetime;
Re:11
petdance on 2003-11-06T19:33:50
Hey, I know, instead of whining in a journal entry you could send me a useful bug report. That might be a little less satisfying, but it would of course have the effect of leading to a fix.Sad to think that people might be satisfied with complaining than with solving the problem.
Re:11
chromatic on 2003-11-06T21:52:21
Patches for humanity welcome. (Not that I have the maintainer's e-mail address
:) Re:11
barbie on 2003-11-07T00:40:59
Another dig. I really am disappointed they had to come from three people who contributions I actually respected.Does it really come down to the level of slashdot comments?
Re:11
chromatic on 2003-11-07T01:15:43
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
barbie on 2003-11-07T00:37:29
Sad to think that the put downs are coming thick and fast despite sending a bug report BEFORE I posted my Journal. AND trying to write a set of test cases.If my contributions are so lowly thought of I'll not bother to help in future.
Re:11
petdance on 2003-11-07T02:03:24
Sad to think that people might be satisfied with complaining than with solving the problem.Sorry, let me rephrases: "Sad to think that could be an expectation." I didn't mean it as a putdown.
Re:11
barbie on 2003-11-07T00:32:57
Hey, you know, instead of berating me, why not check your rt.cpan.org entry. Okay I now know WHY it fails, but at least I took the time write a test case to show why I thought it was wrong.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 and write test cases or even send patches, then I suggest you stop the belittling tone.
Re:11
autarch on 2003-11-07T06:26:51
And I responded to your original bug report as soon as I saw it. From the bug report, I thought you were simply saying that the _new_ delta_days method in 0.18 didn't work as expected, as opposed to saying that the duration object returned by subtraction now had different values.
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 tests not passing on Windows, I'd welcome a fix, but I don't have access to a Win32 compiler, and more importantly, I don't know enough of the details on how IEEE math is implemented on Windows and Perl to understand what the heck is going on here. I actually suspect a Perl bug here, since it also has problems on HPUX.
The reason I berated you was because you took me to task _publically_ in an inappropriate forum for making a decision you didn't like, _and_ to top it off you mentioned a bug you never reported (month of 11) in an incredibly snide manner. You as much as stated that I'm the kind of beeping idiot who's so stupid as to write a DateTime module that doesn't handle November! In fact, I'm well aware of November, and I even know that today is _in_ November.
If you disliked the backwards incompatibility, the right place to complain is the datetime@perl.org list, to which you are welcome to subscribe. There was a public discussion about datetime subtraction, and people seemed to agree that the old behavior was just plain broken, so I changed it. If you were on the list you could've pointed out that your code relied on that behavior and asked for a deprecation period. Even if I hadn't agreed to that, I would've helped you rewrite your code to deal with the change, something I've done for other module authors that rely on DateTime.
This change didn't happen behind your back, nor was it done cavalierly.
It's funny that you acuse others of having this degenerate into a Slashdot forum, when your original posting was very much along those lines.Re:11
barbie on 2003-11-07T09:53:20
I can appreciate there may have been discussion of the datetime list, and had I been subscribed I would certainly have pointed out the fact, that despite it being not entriely accurate, others may rely on the fact that it returned a value that represented the total number of days as opposed to a difference between the month days. Improving the function is one thing, to change it's reason for existing is another.The infinite issue is not something I've had time to look into. My first assumption was that something in ActivePerl optimised infinity minus infinity to zero, rather than the '1.#QNAN' that is expected by the tests.
I don't know why I'm getting the message "The 'month' parameter to DateTime::new did not pass the 'is bet ween 1 and 12' callback" but I am. It may be there is some other calculation that is throwing if off, but the original object creation was for 6th November 2003. I wasn't implying anything regarding your intelligence, I was expressing my frustration that my expectations are broken. I will try and pin the problem down later when I have time. I didn't post a bug report for that because I haven't had time to write a test case. Admittedly I shouldn't have added it to my journal in the heat of the moment, especially following another CPAN test report telling me my code failed.
My original journal was mainly me letting off steam for something I felt extremely frustrated about. My apologies if you felt it was a personal attack. The decision has been made and I have to deal with it. I just wonder whether any accounting or similar code writers are not going to experience the same issues.
int($d1->jd) - int($d2->jd) was what I wanted for days difference. If you can't be bothered to put in that extra time that using a 0.x module requires then you should stick to other, stable CPAN date modules, and/or wait for DateTime 1.0.
Re:DateTime
barbie on 2003-11-07T10:09:31
If you're using a 0.x module you need to be extra careful about what's going on while the authors adjust their API.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.