The Daily WTF: Curious Perversions in Information Technology

2011-02-07 Reply Admin

Just, wow, manual date parsing and validation, no regex, no libraries.

Maybe he thought it would fill several hours of everyone elses time trying to support the monstrosity.

Sadist developer perhaps?

2011-02-07 Reply Admin

Valid Comment?

2011-02-07 Reply Admin

f - askimet says it's ok to post this instead of a normal post, aliquam.

2011-02-07 Reply Admin

I prefer the original code!

2011-02-07 Reply Admin

Another one to file under "Is there any chance this is a solved problem? Shall I spend 10 seconds on Google to see? Naaaah ..."

2011-02-07 Reply Admin

The original code is more robust. The last one might not work, because dates could be implemented differently on different platforms, so the function might not always return the correct result. It's much better to code it yourself, just to be sure.

Captcha: genitus Definition: Someone who thinks with his reproductive organ, but does a very good job of it.

Severity One · 2011-02-07 Reply Admin

This reminds me of a piece of code that I'm looking at right now, from a time that developers would use code that they felt most comfortable with, rather than what's most appropriate. So, if you need to load a two-column file into a database, what do you use? Right, you use C (with C++ syntax).

This function got the current time and put it in a certain format:

void filedate()
{
        struct tm when;
        time_t now;  
        time( &now );
        char *date;
        char result[20];
    char inv_result[20];
                
        when = *localtime( &now );
        when = *localtime(&now);    
        date = asctime(&when);
        

        if(date[8] == ' ')
                        date[8] = '0';

        result[0] = date[8];
        result[1] = date[9];
        switch(when.tm_mon)
        {
        case  0 :
                {
                result[2] = '0';
                result[3] = '1';
                } 
                break;
        case  1 :
                {
                result[2] = '0';
                result[3] = '2';
                }
                break;
        case  2 :
                {
                result[2] = '0';
                result[3] = '3';
                }
                break;
        case  3 :
                {
                result[2] = '0';
                result[3] = '4';
                }
                break;
        case  4 :
                {
                result[2] = '0';
                result[3] = '5';
                }
                break;
        case  5 :
                {
                result[2] = '0';
                result[3] = '6';
                }
                break;
        case  6 :
                {
                result[2] = '0';
                result[3] = '7';
                }
                break;
        case  7 :
                {
                result[2] = '0';
                result[3] = '8';        
                }
                break;
        case  8 :
                {
                result[2] = '0';
                result[3] = '9';
                }
                break;
        case  9 :
                {
                result[2] = '1';
                result[3] = '0';
                }
                break;
        case  10 :
                {
                result[2] = '1';
                result[3] = '1';
                }
                break;
        case  11 :
                {
                result[2] = '1';
                result[3] = '2';
                }
                break;
        }
        result[4] = date[20];
        result[5] = date[21];
        result[6] = date[22];
        result[7] = date[23];
        result[8] = date[11];
        result[9] = date[12];
        result[10] = date[14];
        result[11] = date[15];
        result[12] = date[17];
        result[13] = date[18];
        result[14] = ':';
        result[15] = '\0';
    strcpy(logtime,result);
}

Please note the nice touch of adding the global variable 'logtime'.

2011-02-07 Reply Admin

Severity One:
(with C++ syntax).

W'ah?

dpm · 2011-02-07 Reply Admin

Anonymou5:
The original code is more robust.

I infer that "robust" is your adjective for "handles leap years incorrectly".

Bellinghman · 2011-02-07 Reply Admin

minime:
Severity One:
(with C++ syntax).
W'ah?

Di you not know that 'C++' means take 'C' and increment, but use the pre-increment value?

The programmer in question is scrupulous in following that, using only syntax that will work in vanilla C.

Nagesh · 2011-02-07 Reply Admin

Today my virtual machine got stuck. So I was not able to enter a comment in time. None of the input functions were operational, so I had to reboot my virtual machine twice. Anyway the comment I wanted to make was Sometimes the native functions don't offer the kind of support that your own function can have. This is what is called a classic case of configuration v/s convention.

2011-02-07 Reply Admin

tragomaskhalos:
Another one to file under "Is there *any* chance this is a solved problem? Shall I spend 10 seconds on Google to see? Naaaah ..."

On the contrary, probably did spend 10 seconds on Google, skimmed right past the simple answer, copypasta'd some random code, and rebuggered it until it sort of worked.

CAPTCHA: nisl. fo'shisl.

2011-02-07 Reply Admin

Is it just me, or will that function fail on any date after 2010?

2011-02-07 Reply Admin

Anonymou5:
The original code is more robust. The last one might not work, because dates could be implemented differently on different platforms, so the function might not always return the correct result. It's much better to code it yourself, just to be sure.

Good thinking. I never use any built-in function because I can never be sure they are going to give me the right result.

Now excuse me while I get back to this great program I am developing that will allow me to add two numbers together.

Captcha: nobis = someone who never uses built-in functions

SCSimmons · 2011-02-07 Reply Admin

Ah, leap years ... In March 2009, I had to fix a bug I'd written myself circa 2003. The bit in question was a nightly update process that was supposed to add a row for each entry in a database on the anniversary date of the original entry. I knew that leap years would be an issue when I wrote the code (what's the anniversary date for 2/29?) & put in a workaround that was supposed to apply that insert on 3/1 of the next year.

That process did not generate the anniversary entries on 3/1/2009 for the entries from 2/29/2008, and when I checked my code, I found it was poorly thought-out and couldn't actually work. After fixing it, it occurred to me to wonder why the problem didn't get caught in 2005, when it should have had the same problem. A little research turned up the fact that 2/29/2004 was a Sunday, and the business process that generated initial entries was only active Monday through Saturday. (The people who made the entries didn't work on Sunday, so the Sunday entries were made on Monday.) Hence, a leap year bug that took six years to manifest.

I have a reminder in my calendar for 3/1/2013 to verify that my fix actually works correctly in production. :)

(I think I've mentioned before that at my previous job, I fixed a Y2K bug in a web application in 1999. The application had originally been written in 1998. The developer who wrote it was no longer with the company, so I never got to ask what the hell he was thinking.)

Zylon · 2011-02-07 Reply Admin

"Last year (2010) was a bigger than he figured, one, as several developers..."

I'm assuming this sentence was passed through a few translation filters for some nefarious reason.

2011-02-07 Reply Admin

From my experience in the past 20 years: all junior developers like to WRITE code... well... copy-n-paste-it but still have code. And they are tireless... the more bugs they have the more code they write introducing more and more new bugs, sometimes solving old ones... eventually...

2011-02-07 Reply Admin

Ben:
tragomaskhalos:
Another one to file under "Is there *any* chance this is a solved problem? Shall I spend 10 seconds on Google to see? Naaaah ..."

On the contrary, probably did spend 10 seconds on Google, skimmed right past the simple answer, copypasta'd some random code, and rebuggered it until it sort of worked.

CAPTCHA: nisl. fo'shisl.

Yeah, either that or spent 5 seconds on Google and used the ridiculous method that unfortunately is the #1 hit for a badly searched for solution.

GIYF...unless your co-workers blindy trust that hit #1 is the way to solve a problem, then it's your enemy :-/

shinobu · 2011-02-07 Reply Admin

I'm really glad that I'll be retired to the day when developers will have to deal with the Y2Ki bug.

frits · 2011-02-07 Reply Admin

Why didn't he just use Zeller's algorithm and check for DAY_NOT_FOUND?

2011-02-07 Reply Admin

Update the code once a year? No problem. I once had to fix an application whose strategy for dealing with daylight-saving time was for the code to be changed every six months.

HellKarnassus · 2011-02-07 Reply Admin

tragomaskhalos:
Another one to file under "Is there *any* chance this is a solved problem? Shall I spend 10 seconds on Google to see? Naaaah ..."

What if the frist result leads you to this site? Hmmmm?

BTW, my first job out of school was in a consulting company that blocked all Internet access, except for the project leaders in some special projects. So I'm suspecting they managed to reinvent the wheel several times, except for the most experienced developers, maybe. Got out of there after the first month but that was the least important of the reasons.

Oh, and FRITS post!! (of mine on this website, of course)

2011-02-07 Reply Admin

Been there too. Ours worked around defects in remote sensing gear that was mounted on pig farms all over the midwest. Why they reported in local time instead of GMT is a good question, but once broken, there really wasn't anything to do but fix the code twice a year.

2011-02-07 Reply Admin

At least it didn't do a File Manager style error... 98 99 :0 :1

That code made me cry.

2011-02-07 Reply Admin

TRWFT is that it didn't break on October 23, 2010 (or other arbitrary, random date in the 'distant' future relative to when it was written) since the original developers obviously thought the code wouldn't last that long. After all, why would anyone want to represent future dates? And even then, nobody should ever be using this code for too long because everybody knows that old code is buggy.

2011-02-07 Reply Admin

In their defense... isn't it possible that one of the organization's business rules is: "Only dates from this year or previous years can be entered"

I agree there would be a (far) better way to implement that rule... but the original code does solve that problem (with an annual update) and the new code does not.

Just sayin'

2011-02-07 Reply Admin

Matthew:
Update the code once a year? No problem. I once had to fix an application whose strategy for dealing with daylight-saving time was for the code to be changed every six months.

I had something similar at my last job, but not an application; rather an HP-UX server. There was an incredible amount of twatting around involved in taking it down and back up -- services would get very confused if they were still running, so everything had to be stopped; also if you were putting the time BACK then you'd have to wait around for over an hour before bringing everything up in case the badly-written Oracle applications got confused.

Before I did it for my first time, I did a quick Google and found that HP had released a patch several years before to handle the change automatically. Nobody was aware of this. When I left 18 months later, they still hadn't authorised me to patch it because they were scared.

2011-02-07 Reply Admin

I don't think that will give them what they are looking for.

IsDate("1a") will return true.

They will also have to check thisDate > 1 to know whether that is actually a valid date.

2011-02-07 Reply Admin

Seen this so many times it doesn't even register on my WTF-o-meter any more. Either they don't know about the in-built functions or they simply don't want to use them, either way it's a good indication that you need a new developer.

2011-02-07 Reply Admin

That isn't quite a correct fix. The original code appears to (badly) reject dates that are in the next calendar year (possibly it's supposed to reject dates in the future, which is a not uncommon requirement, but it does this badly of course); I'm not defending the way it does it, but if you're going to replace code, it's always safer to replace it with code that is functionally identical.

Of course the leap year logic is wrong, but it will work until 2100. :)

dohpaz42 · 2011-02-07 Reply Admin

frits:
Why didn't he just use Zeller's algorithm and check for FILE_NOT_FOUND?

FTFY

2011-02-07 Reply Admin

Lest we perpetuate the myth that Y2K was no big deal, allow me to relate a tale from the trenches. We embarked on one of the biggest software projects our large interstate corporation had ever attempted -- with an absolutely immovable deadline. We spent literally millions of dollars testing and certifying everything, finding and fixing a lot of bugs, some of which would have been quite serious.

And after all that, we had a sizable crew, including myself, at work starting 6PM New Year's Eve. Never mind that it is a thousand years to the next one; no parties for us. One of our larger vendors (think ERP style system for healthcare) had a programmer on site, who was checking in with her peers at other sites every 10 minutes or so. Luckily we were in a western time zone, because at 10:00 PM our time one of the eastern time zone sites went belly up. Frantic work by the brightest and best got that site back online, and developed a patch that we got installed and tested before our own midnight arrived.

Y2K was a non-event only because of the long hard work of thousands of dedicated people like that.

2011-02-07 Reply Admin

Vinny:
Been there too. Ours worked around defects in remote sensing gear that was mounted on pig farms all over the midwest. Why they reported in local time instead of GMT is a good question, but once broken, there really wasn't anything to do but fix the code twice a year.

Why couldn't you change it to behave differently when daylight savings time is in effect?

2011-02-07 Reply Admin

I can't wait until we go through this whole thing again in 2038. I feel like the entire software engineering profession is a skit played to the tune of "Yakity Sax".

dohpaz42 · 2011-02-07 Reply Admin

Andrew:
... Y2K was a non-event only because of the long hard work of thousands of dedicated people like that.

Don't worry, we'll get to go through it all over again in 2038: http://en.wikipedia.org/wiki/Year_2038_problem

If only we had the foresight and technology to fix it now...

2011-02-07 Reply Admin

Andrew:
Lest we perpetuate the myth that Y2K was no big deal, allow me to relate a tale from the trenches. We embarked on one of the biggest software projects our large interstate corporation had ever attempted -- with an absolutely immovable deadline. We spent literally millions of dollars testing and certifying everything, finding and fixing a lot of bugs, some of which would have been quite serious.
And after all that, we had a sizable crew, including myself, at work starting 6PM New Year's Eve. Never mind that it is a thousand years to the next one; no parties for us. One of our larger vendors (think ERP style system for healthcare) had a programmer on site, who was checking in with her peers at other sites every 10 minutes or so. Luckily we were in a western time zone, because at 10:00 PM our time one of the eastern time zone sites went belly up. Frantic work by the brightest and best got that site back online, and developed a patch that we got installed and tested before our own midnight arrived.

Y2K was a non-event only because of the long hard work of thousands of dedicated people like that.

Amen to that. Fixed an interesting one myself on a 3rd party control library.

Put in 1999 and then increment it by one (for some reason to do with validation; I forget) what do you think the answer was? Yup, that's right, 3000.

Go figure.

2011-02-07 Reply Admin

I remember when the BBC's esteemed Radio 4 broadcast a programme about the Y2K bug at the time and wheeled in an 'expert' who said "...and, of course, 2000 is not a leap year..."

2011-02-07 Reply Admin

Anonymou5:
The original code is more robust. The last one might not work, because dates could be implemented differently on different platforms, so the function might not always return the correct result. It's much better to code it yourself, just to be sure.
Captcha: genitus Definition: Someone who thinks with his reproductive organ, but does a very good job of it.

I'm not sure whether your are being sarcastic but you had the beginnings of a very valid point - the existing code checks for a valid date in a specific format; the new code checks if the date is valid in the context of the current culture.

if someone is using the application in a country other the one it was written (note for US citizens: other countries really do exist, and some of them even have computers), this change could cause many horrible problems.

of course the solution is not to code date processing code yourself but to always know what format and culture the date is expected to be in

2011-02-07 Reply Admin

anon:
I can't wait until we go through this whole thing again in 2038. I feel like the entire software engineering profession is a skit played to the tune of "Yakity Sax".

Software so-called engineering is so far away from real engineering it ain't even funny. John Zachman hypothesizes that the profession is only about half way through its maturity process; it'll be another 40 or so years before it's professionalized. IT hasn't had its Chernobyl yet.

2011-02-07 Reply Admin

TRWTF is VB. Yup! If this had been written in C++ or Python it would not have existed.

2011-02-07 Reply Admin

dohpaz42:
Andrew:
... Y2K was a non-event only because of the long hard work of thousands of dedicated people like that.

Don't worry, we'll get to go through it all over again in 2038: http://en.wikipedia.org/wiki/Year_2038_problem

If only we had the foresight and technology to fix it now...

If only we had the money, resources and lack of more pressing issues to fix it now.

FTFY

2011-02-07 Reply Admin

Andrew:
Lest we perpetuate the myth that Y2K was no big deal, allow me to relate a tale from the trenches. We embarked on one of the biggest software projects our large interstate corporation had ever attempted -- with an absolutely immovable deadline. We spent literally millions of dollars testing and certifying everything, finding and fixing a lot of bugs, some of which would have been quite serious.
And after all that, we had a sizable crew, including myself, at work starting 6PM New Year's Eve. Never mind that it is a thousand years to the next one; no parties for us. One of our larger vendors (think ERP style system for healthcare) had a programmer on site, who was checking in with her peers at other sites every 10 minutes or so. Luckily we were in a western time zone, because at 10:00 PM our time one of the eastern time zone sites went belly up. Frantic work by the brightest and best got that site back online, and developed a patch that we got installed and tested before our own midnight arrived.

Y2K was a non-event only because of the long hard work of thousands of dedicated people like that.

The software industry was damned whatever happened:

If there were no (or few) problems then it was all an over-reaction and an excuse to fleece people.
If it had all gone wrong we'd all be labelled as incompetent (and we'd fleeced people anyway)

Fortunately the reality was the former, but either way we were going to be slagged off.

Zylon · 2011-02-07 Reply Admin

dohpaz42:
frits:
Why didn't he just use Zeller's algorithm and check for FILE_NOT_FOUND?

FTFY

No, you just took something vaguely clever and made it stupid.

2011-02-07 Reply Admin

Thats some odd school BASIC programming. Check out any VB/QB code archives and you'll find stuff that looks just like that.

Not that its a bad thing, it's just that kids wrote it when they were 12 and didn't know everything.

2011-02-07 Reply Admin

Andrew:
Y2K was a non-event only because of the long hard work of thousands of dedicated people like that.

Thousands of dedicated people? That's a tiny number considering the hundereds of millions of systems that were potentially at risk from the issue. I think you've just highlighted how trivial Y2K was - a few thousand incidents worldwide, handled by a few thousand grunts who obviously had nothing better to do. I really hope the Unix timestamp overflow of 2038 proves more eventful. Of course, even if it's an extinction-level event we'll never convince the world to give a shit after we called wolf over Y2K. "Another Y2K? Oh noes, that was so bad the last time, LOL!!! Here, I annotated a cat to reflect my deep concern about this most serious event, ROFL!1!"

2011-02-07 Reply Admin

GAZZA:
That isn't quite a correct fix. The original code appears to (badly) reject dates that are in the next calendar year (possibly it's supposed to reject dates in the future, which is a not uncommon requirement, but it does this badly of course); I'm not defending the way it does it, but if you're going to replace code, it's always safer to replace it with code that is functionally identical.
Of course the leap year logic is wrong, but it will work until 2100. :)

Eh, that's what QA is for, right?

2011-02-07 Reply Admin

To me this is only a minor WTF. I am sure that if you had perfect knowledge of boost and, of course, the stdlib that you could replace 60% of my code. Throw in a few other libraries and it could shrink down some more.

2011-02-07 Reply Admin

And let's not forget that 2000 was a leap year, being the exception-to-the-exception. Back in Y2K-n, we got several bug reports stating that our IsLeap() function returned TRUE for 2000. (Apparently, more than one companies' Y2K-compliance tests were buggy.)

2011-02-07 Reply Admin

Yeah it does which is why the ticket came in in the first place. The first thing I did after crying was submit it here so I could share the pain.

2011-02-07 Reply Admin

I think that most of the code I wrote pre-Y2K will be fine until 2080 when input like 010180 will of course be translated as 01/01/1980.

Annual Y2K

Leave a comment on “Annual Y2K”