When is a bug, not a bug? When it is a documented feature.
Okay, so some background. I’m writing a performance report to replace a manual process, this report tracks the time that results are delivered to customers and did it meet delivery deadline. I know from the previous manual reports (and my own estimates) that the monthly performance is about 90% (give or take 5%); you can imagine my surprise when my report showed that between April and October our performance (according to the report) was 0% – which I know to be incorrect.
First I thought it was a program logic bug, but no, the logic was fine. Thinking it might be a perl bug, I rewrote part of it as Windows Batch commands – same result. Then I noticed that the DIR command reported a one hour difference in timestamps to what Windows Explorer reported, but only in the middle of the year. That’s when I realized – it was a Daylight Savings issue. One way reported the timestamp allowing for Daylight Savings, the other did not.
Now this is where things get interesting. I had been working on a Windows XP machine (I know, I know, don’t tell me), so then I tried a Windows 7 machine – same result. Huh? How could such an obvious bug not be fixed?
Some more research found that this was a well known ‘issue’ – which I can not call a ‘bug’ since Microsoft have documented that this is exactly how it works. Refer to this article.
http://search.cpan.org/~shay/Win32-UTCFileTime-1.56/lib/Win32/UTCFileTime.pm
So it’s not a bug because it’s documented, which is a bit like having a maths library where 1+1=6 but it’s okay because it is meant to. Sorry, but are you kidding me?
I implemented the above fix into my original perl program and the report is now showing 90% +- 5% as expected.
Just when I thought I had seen everything.