Bug #98287 for DateConvert: Several Bugs in Date::Convert

Greetings. I recently came across the Date::Convert module in Perl, and found some bugs with it. It looks like it hasn’t been maintained in a while, so I don’t know if you’re still supporting it or not. At any rate, I do have solutions for the bugs. I don’t know what the protocol ought to be, so I’ll just start by reporting it to you, and let you suggest how to proceed.   The major problem is that it just doesn’t work right for certain years. For example, if you run your “quick Greg -> Hebrew conversion program”, and enter 1957 3 2, you get the wrong answer (which should be 5717 Adar 29, but see the final paragraph below). If you enter 1957 9 25, you not only get the wrong answer (should be 5717 Elul 29), but you also get a warning message “Impossible year length”, a “should not happen” condition. The problem seemed to be somewhere in the rosh subroutine; I was unable to debug it successfully, but I was able to substitute a modified version which I use in Javascript, and that eliminated the problem.   A less serious problem is that it doesn’t handle Julian dates properly for dates on or after February 29 in the “trouble years”. For example, the following code: $date=new Date::Convert::Julian(2100, 3, 1); convert Date::Convert::Gregorian $date; convert Date::Convert::Julian $date; returns “2100 Feb 29”, not “2100 Mar 1”. In fact, the following returns an error and should not (the date is valid): $date=new Date::Convert::Julian(2100, 2, 29);   I also have a fix for the only official open bug, namely “a request that the constructor with no args defaults to today”, which certainly seems like a reasonable suggestion.   Finally, I added code to use the month name “Adar I” rather than “Adar” in leap years, and some additional methods which make date manipulation easier (day of year, number of days in year, weekday, weekday of Rosh Hashanah). Owen Leibman