Bug in Calendar Calcs program

Few of you would have noticed. But there was a showstopper bug in our calendar program Calendar Calcs. It was reported by reader Greg H., and we had to yank the page for a few days.

The bug is fixed and posted to our Bug List page. For your own amusement only, here is the text of the thank you note I sent on this hard-to-isolate bug. (For me at least) the detective trail is fascinating:

Greg, the bug is fixed and posted. Thanks so much again for finding and reporting it.

It was a challenge to pin down but a lot of fun. The pattern was goofy, a whole block of years 1965-2004 where I could not reproduce the problem.

But in other blocks, starting at 2005 and going forward, the program result was a day behind the correct result, but only for the years after a leap year.

Between 1964 and going backwards at least a century, the program result was a day ahead of the correct result, but only for leap years.

That’s right, it looked like “One of those scenarios where you have to have a blue shoe on your left foot on the TX side of the border pointing south, and a red shoe on the right foot in Oklahoma, pointing east, and singing ‘I want to be a cowboy’ “

It turned out to be a rounding error. C assumes a number is an integer (whole number) unless you declare it otherwise. Perl assumes you know what you’re doing. Once I produced rounding issues in a test version of my C-to-Perl conversion program, I was able to ask, “but wait a minute, number of days is always in integers; why and where are we rounding at all?”

Let me know if you find any other issues. I tested and retested about a hundred dates between 1864 and 2065, “before” and “after” my fix. All of the problem results and good results I recorded “before” are now good results “after”.

I am glad someone else is finding the utility useful and sorry it had a bug!



721 total views, 1 views today