It’s not a bug – it’s a feature

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.

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.




Need help? Let me take care of your IT issues.

Share this page

Share on facebook
Share on linkedin
Share on twitter
Share on print
Share on email
Scroll to Top