• Jimmy Jones (unregistered) in reply to dohpaz42
    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...

    Most of the important C libraries have been using use a 64 bit time_t for a number of years now.

    There's plenty of time left for this to propagate, it will mostly be a non-issue.

  • A. N. (unregistered) in reply to Lorens
    Lorens:
    SpamAssassin managed to insert a check that the year of a mail was of the form 200[0-9], AND misdocument it, AND when discovered in january 2010 just change to expire in 2020 instead

    At our uni computer related problems tend to pop up every new year. Usually it's just a bunch of expired SSL certificates, but when 2010 came all IT services requiring Shibboleth login stopped working. With exam week and homework deadlines rapidly closing in a hungover sysadmin was summoned from his two-and-a-half days' national holiday. Luckily a lone C/C++ course assistant had already located the problem and all internal services were brought up. However, it took half a week before all third party services were working again.

    The culprit? The Shibboleth sample Service Provider configuration file had an expiration date of January 1st 2010.

  • Brendan (unregistered) in reply to filmil
    filmil:
    I wonder how interesting the daily WTF articles would be if people just wrote unit tests for their code.

    I wonder why completely stupid, borked and wrong unit tests aren't posted regularly on TDWTF too...

  • Anonymous (unregistered) in reply to Brendan
    Brendan:
    filmil:
    I wonder how interesting the daily WTF articles would be if people just wrote unit tests for their code.

    I wonder why completely stupid, borked and wrong unit tests aren't posted regularly on TDWTF too...

    We see them plenty often enough.
  • Brendan (unregistered) in reply to Anonymous
    Anonymous:
    Brendan:
    filmil:
    I wonder how interesting the daily WTF articles would be if people just wrote unit tests for their code.

    I wonder why completely stupid, borked and wrong unit tests aren't posted regularly on TDWTF too...

    We see them plenty often enough.

    You're right.

    Obviously if unit tests are the silver bullet to prevent 100% of all bugs in code, we need "unit test tests" as a silver bullet to prevent 100% of all bugs in unit tests.

    Of course we'd need to shift all the competent people into the new "unit test testing" roles; and because there's only so many competent people we'll need to use incompetent people to fill the programming roles. Unfortunately all these new incompetent people will really stress the unit testing (and the unit test testing), so you'd need to add "unit test test testing", and...

    Eventually, there'll be at least 20 levels of testing, and anyone with enough intelligence to sit on a chair without falling off will be working as programmers (due to the skills shortage).

    That'll work, won't it? :-)

  • (cs) in reply to minime
    minime:
    Severity One:
    (with C++ syntax).
    W'ah?
    Meaning that whilst the code would be valid C if certain statements would be put in a different order, his source files would end in .cpp because, well, it wasn't valid C, even though not a single C++ feature (other than variable declaration anywhere) was used.
  • ISO 8601 (unregistered)

    TRWTF = countries that use dates in mm/dd/yy format.

    It defies logic and common sense.

    (UK-based poster)

  • Anonymous (unregistered) in reply to ISO 8601
    ISO 8601:
    TRWTF = countries that use dates in mm/dd/yy format.

    It defies logic and common sense.

    (UK-based poster)

    I'm from the UK but I still recognise that there is a very good reason to use MM/DD/YY - sort ordering. MM/DD/YY orders the same irrespective of whether you sort the data alphabetically or numerically, whereas the UK's DD/MM/YY scheme orders differently based on whether you sort alphabetically or numerically:

    01/01/01 - 1st Jan 01 } 01/02/01 - 1st Feb 01 } DD/MM/YY alphabetic ordering (non-numeric) 02/01/01 - 2nd Jan 01 }

    01/01/01 - 1st Jan 01 } 01/02/01 - 2st Jan 01 } MM/DD/YY alphabetic ordering (numeric) 02/01/01 - 1st Feb 01 }

  • Anon T (unregistered) in reply to qbolec

    Using regexps for date validation is not that clever. Ofcourse the whole date can be validated using a single regex but the pattern gets like 80 characters long and very difficult to read beacause all the leap years, differences in amount of days in a month and such. Checking just the individual parts of a date string is questionable as well because each part is dependent on the other parts. Regular expressions are best for pattern matching, not for arithmetic comparisons.

  • foo (unregistered) in reply to Anonymous
    Anonymous:
    ISO 8601:
    TRWTF = countries that use dates in mm/dd/yy format.

    It defies logic and common sense.

    (UK-based poster)

    I'm from the UK but I still recognise that there is a very good reason to use MM/DD/YY - sort ordering. MM/DD/YY orders the same irrespective of whether you sort the data alphabetically or numerically, whereas the UK's DD/MM/YY scheme orders differently based on whether you sort alphabetically or numerically:

    01/01/01 - 1st Jan 01 } 01/02/01 - 1st Feb 01 } DD/MM/YY alphabetic ordering (non-numeric) 02/01/01 - 2nd Jan 01 }

    01/01/01 - 1st Jan 01 } 01/02/01 - 2st Jan 01 } MM/DD/YY alphabetic ordering (numeric) 02/01/01 - 1st Feb 01 }

    Thanks for posting this here -- after so many comments talking about unit tests. (Hint: Test your assertion with different years.) FTR, though it should be obvious by now, YY/MM/DD, or better yet, YYYY/MM/DD, has the property you describe.

  • fake frits 37 (unregistered) in reply to dohpaz42
    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...

    why? we all made loads of cash out of it...

  • fake frits 37 (unregistered) in reply to anon
    anon:
    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.

    I thought we were quite successful in blaming it on old father time.

  • anon (unregistered) in reply to Severity One
    Severity One:
    minime:
    Severity One:
    (with C++ syntax).
    W'ah?
    Meaning that whilst the code would be valid C if certain statements would be put in a different order, his source files would end in .cpp because, well, it wasn't valid C, even though not a single C++ feature (other than variable declaration anywhere) was used.

    C99 allows variable declaration anywhere.

    Seriously, what is it with people? This standard is now twelve years old.

  • Anonymous (unregistered) in reply to foo
    foo:
    Anonymous:
    ISO 8601:
    TRWTF = countries that use dates in mm/dd/yy format.

    It defies logic and common sense.

    (UK-based poster)

    I'm from the UK but I still recognise that there is a very good reason to use MM/DD/YYYY - sort ordering. MM/DD/YYYY orders the same irrespective of whether you sort the data alphabetically or numerically, whereas the UK's DD/MM/YYYY scheme orders differently based on whether you sort alphabetically or numerically:

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 1st Feb 01 } DD/MM/YYYY alphabetic ordering (non-numeric) 02/01/2001 - 2nd Jan 01 }

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 2st Jan 01 } MM/DD/YYYY alphabetic ordering (numeric) 02/01/2001 - 1st Feb 01 }

    Thanks for posting this here -- after so many comments talking about unit tests. (Hint: Test your assertion with different years.) FTR, though it should be obvious by now, YY/MM/DD, or better yet, YYYY/MM/DD, has the property you describe.
    Well done, you spotted my deliberate mistake - I couldn't resist it since we were talking about Y2K, which is kind of the root issue here. I have now updated my post accordingly but I'm afraid you were wrong about using YYYY/MM/DD - this is not a helpful scheme at all and is not required to support equivalent alphabetic/numeric sorting. You simply need to increase the precision of the year value, as in my example above (MM/DD/YYYY instead of MM/DD/YY - there is absolutely no reason to use YYYY/MM/DD, that's just dumb).

    Thanks for playing!

  • (cs) in reply to anon
    anon:
    Severity One:
    Meaning that whilst the code would be valid C if certain statements would be put in a different order, his source files would end in .cpp because, well, it wasn't valid C, even though not a single C++ feature (other than variable declaration anywhere) was used.
    C99 allows variable declaration anywhere.

    Seriously, what is it with people? This standard is now twelve years old.

    Ah, classic mistake: you're assuming that this developer would stick to the standard or, indeed, be aware of it.

    The company did the only thing possible to prevent further development disasters: he was made a line manager.

  • foo (unregistered) in reply to Anonymous
    Anonymous:
    foo:
    Anonymous:
    ISO 8601:
    TRWTF = countries that use dates in mm/dd/yy format.

    It defies logic and common sense.

    (UK-based poster)

    I'm from the UK but I still recognise that there is a very good reason to use MM/DD/YYYY - sort ordering. MM/DD/YYYY orders the same irrespective of whether you sort the data alphabetically or numerically, whereas the UK's DD/MM/YYYY scheme orders differently based on whether you sort alphabetically or numerically:

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 1st Feb 01 } DD/MM/YYYY alphabetic ordering (non-numeric) 02/01/2001 - 2nd Jan 01 }

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 2st Jan 01 } MM/DD/YYYY alphabetic ordering (numeric) 02/01/2001 - 1st Feb 01 }

    Thanks for posting this here -- after so many comments talking about unit tests. (Hint: Test your assertion with different years.) FTR, though it should be obvious by now, YY/MM/DD, or better yet, YYYY/MM/DD, has the property you describe.
    Well done, you spotted my deliberate mistake - I couldn't resist it since we were talking about Y2K, which is kind of the root issue here. I have now updated my post accordingly but I'm afraid you were wrong about using YYYY/MM/DD - this is not a helpful scheme at all and is not required to support equivalent alphabetic/numeric sorting. You simply need to increase the precision of the year value, as in my example above (MM/DD/YYYY instead of MM/DD/YY - there is absolutely no reason to use YYYY/MM/DD, that's just dumb).

    Thanks for playing!

    Maybe you should actually read the post by the other Anonymous (obviously not you) that I was replying too. He was talking about numerical vs. alphabetical ordering which doesn't work with MM/DD/YY[YY].

  • anon (unregistered) in reply to Anonymous
    Anonymous:
    foo:
    Anonymous:
    ISO 8601:
    TRWTF = countries that use dates in mm/dd/yy format.

    It defies logic and common sense.

    (UK-based poster)

    I'm from the UK but I still recognise that there is a very good reason to use MM/DD/YYYY - sort ordering. MM/DD/YYYY orders the same irrespective of whether you sort the data alphabetically or numerically, whereas the UK's DD/MM/YYYY scheme orders differently based on whether you sort alphabetically or numerically:

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 1st Feb 01 } DD/MM/YYYY alphabetic ordering (non-numeric) 02/01/2001 - 2nd Jan 01 }

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 2st Jan 01 } MM/DD/YYYY alphabetic ordering (numeric) 02/01/2001 - 1st Feb 01 }

    Thanks for posting this here -- after so many comments talking about unit tests. (Hint: Test your assertion with different years.) FTR, though it should be obvious by now, YY/MM/DD, or better yet, YYYY/MM/DD, has the property you describe.
    Well done, you spotted my deliberate mistake - I couldn't resist it since we were talking about Y2K, which is kind of the root issue here. I have now updated my post accordingly but I'm afraid you were wrong about using YYYY/MM/DD - this is not a helpful scheme at all and is not required to support equivalent alphabetic/numeric sorting. You simply need to increase the precision of the year value, as in my example above (MM/DD/YYYY instead of MM/DD/YY - there is absolutely no reason to use YYYY/MM/DD, that's just dumb).

    Thanks for playing!

    I'm assuming you're deliberately trolling, but what the hell.

    MM/DD/YYYY - sorted numerically

    01/01/2011 01/02/1957 01/03/2038

    etc.

    There's a reason why YYYY-MM-DD is the ISO 8601 standard date format: it's the only one that sorts correctly with a trivial sort.

    As an added bonus, it means that the obnoxious Europeans who insist on DD/MM/YYYY and the obnoxious Americans who insist on MM/DD/YYYY are both equally wrong!

  • OTTA (unregistered) in reply to Anonymous

    So when does the 1st Jan 2002 appear in your world? Apparently before February 2001.

    Thanks for playing!

  • Anonymous (unregistered) in reply to foo
    foo:
    Anonymous:
    foo:
    Anonymous:
    ISO 8601:
    TRWTF = countries that use dates in mm/dd/yy format.

    It defies logic and common sense.

    (UK-based poster)

    I'm from the UK but I still recognise that there is a very good reason to use MM/DD/YYYY - sort ordering. MM/DD/YYYY orders the same irrespective of whether you sort the data alphabetically or numerically, whereas the UK's DD/MM/YYYY scheme orders differently based on whether you sort alphabetically or numerically:

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 1st Feb 01 } DD/MM/YYYY alphabetic ordering (non-numeric) 02/01/2001 - 2nd Jan 01 }

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 2st Jan 01 } MM/DD/YYYY alphabetic ordering (numeric) 02/01/2001 - 1st Feb 01 }

    Thanks for posting this here -- after so many comments talking about unit tests. (Hint: Test your assertion with different years.) FTR, though it should be obvious by now, YY/MM/DD, or better yet, YYYY/MM/DD, has the property you describe.
    Well done, you spotted my deliberate mistake - I couldn't resist it since we were talking about Y2K, which is kind of the root issue here. I have now updated my post accordingly but I'm afraid you were wrong about using YYYY/MM/DD - this is not a helpful scheme at all and is not required to support equivalent alphabetic/numeric sorting. You simply need to increase the precision of the year value, as in my example above (MM/DD/YYYY instead of MM/DD/YY - there is absolutely no reason to use YYYY/MM/DD, that's just dumb).

    Thanks for playing!

    Maybe you should actually read the post by the other Anonymous (obviously not you) that I was replying too. He was talking about numerical vs. alphabetical ordering which doesn't work with MM/DD/YY[YY].
    The fuck are you talking about? Have you even been reading these comments? Maybe you don't understand what I mean by "numeric" so to spell it out: alphabetic ordering is the same as the natural date ordering (numeric by date). Make sense to you now?

    DD/MM/YYYY sorted alphabetically:

    01/02/1903 01/02/2003 02/01/1903 02/01/2003

    DD/MM/YYYY sorted by date:

    01/02/1903 02/01/1903 01/02/2003 02/01/2003

    So alphabetic and date ordering are different for DD/MM/YYYY

    MM/DD/YYYY sorted alphabetically:

    01/02/1903 02/01/1903 01/02/2003 02/01/2003

    MM/DD/YYYY sorted by date:

    01/02/1903 02/01/1903 01/02/2003 02/01/2003

    So alphabetic and date ordering are the same for MM/DD/YYYY

    WTF don't you understand about this incredibly simple concept?

  • Nagesh Kukunoor (unregistered) in reply to Anonymous
    Anonymous:
    foo:
    Anonymous:
    foo:
    Anonymous:
    ISO 8601:
    TRWTF = countries that use dates in mm/dd/yy format.

    It defies logic and common sense.

    (UK-based poster)

    I'm from the UK but I still recognise that there is a very good reason to use MM/DD/YYYY - sort ordering. MM/DD/YYYY orders the same irrespective of whether you sort the data alphabetically or numerically, whereas the UK's DD/MM/YYYY scheme orders differently based on whether you sort alphabetically or numerically:

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 1st Feb 01 } DD/MM/YYYY alphabetic ordering (non-numeric) 02/01/2001 - 2nd Jan 01 }

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 2st Jan 01 } MM/DD/YYYY alphabetic ordering (numeric) 02/01/2001 - 1st Feb 01 }

    Thanks for posting this here -- after so many comments talking about unit tests. (Hint: Test your assertion with different years.) FTR, though it should be obvious by now, YY/MM/DD, or better yet, YYYY/MM/DD, has the property you describe.
    Well done, you spotted my deliberate mistake - I couldn't resist it since we were talking about Y2K, which is kind of the root issue here. I have now updated my post accordingly but I'm afraid you were wrong about using YYYY/MM/DD - this is not a helpful scheme at all and is not required to support equivalent alphabetic/numeric sorting. You simply need to increase the precision of the year value, as in my example above (MM/DD/YYYY instead of MM/DD/YY - there is absolutely no reason to use YYYY/MM/DD, that's just dumb).

    Thanks for playing!

    Maybe you should actually read the post by the other Anonymous (obviously not you) that I was replying too. He was talking about numerical vs. alphabetical ordering which doesn't work with MM/DD/YY[YY].
    The fuck are you talking about? Have you even been reading these comments? Maybe you don't understand what I mean by "numeric" so to spell it out: alphabetic ordering is the same as the natural date ordering (numeric by date). Make sense to you now?

    DD/MM/YYYY sorted alphabetically:

    01/02/1903 01/02/2003 02/01/1903 02/01/2003

    DD/MM/YYYY sorted by date:

    01/02/1903 02/01/1903 01/02/2003 02/01/2003

    So alphabetic and date ordering are different for DD/MM/YYYY

    MM/DD/YYYY sorted alphabetically:

    01/02/1903 02/01/1903 01/02/2003 02/01/2003

    MM/DD/YYYY sorted by date:

    01/02/1903 02/01/1903 01/02/2003 02/01/2003

    So alphabetic and date ordering are the same for MM/DD/YYYY

    WTF don't you understand about this incredibly simple concept?

    I have much to learn from you noble troll. I have been practising hard but you are clearly very experienced.

  • (cs)

    I am from India and we use DD/MM/YYYY in our date formats.

  • anon (unregistered) in reply to Anonymous
    Anonymous:
    foo:
    Anonymous:
    foo:
    Anonymous:
    ISO 8601:
    TRWTF = countries that use dates in mm/dd/yy format.

    It defies logic and common sense.

    (UK-based poster)

    I'm from the UK but I still recognise that there is a very good reason to use MM/DD/YYYY - sort ordering. MM/DD/YYYY orders the same irrespective of whether you sort the data alphabetically or numerically, whereas the UK's DD/MM/YYYY scheme orders differently based on whether you sort alphabetically or numerically:

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 1st Feb 01 } DD/MM/YYYY alphabetic ordering (non-numeric) 02/01/2001 - 2nd Jan 01 }

    01/01/2001 - 1st Jan 01 } 01/02/2001 - 2st Jan 01 } MM/DD/YYYY alphabetic ordering (numeric) 02/01/2001 - 1st Feb 01 }

    Thanks for posting this here -- after so many comments talking about unit tests. (Hint: Test your assertion with different years.) FTR, though it should be obvious by now, YY/MM/DD, or better yet, YYYY/MM/DD, has the property you describe.
    Well done, you spotted my deliberate mistake - I couldn't resist it since we were talking about Y2K, which is kind of the root issue here. I have now updated my post accordingly but I'm afraid you were wrong about using YYYY/MM/DD - this is not a helpful scheme at all and is not required to support equivalent alphabetic/numeric sorting. You simply need to increase the precision of the year value, as in my example above (MM/DD/YYYY instead of MM/DD/YY - there is absolutely no reason to use YYYY/MM/DD, that's just dumb).

    Thanks for playing!

    Maybe you should actually read the post by the other Anonymous (obviously not you) that I was replying too. He was talking about numerical vs. alphabetical ordering which doesn't work with MM/DD/YY[YY].
    The fuck are you talking about? Have you even been reading these comments? Maybe you don't understand what I mean by "numeric" so to spell it out: alphabetic ordering is the same as the natural date ordering (numeric by date). Make sense to you now?

    DD/MM/YYYY sorted alphabetically:

    01/02/1903 01/02/2003 02/01/1903 02/01/2003

    DD/MM/YYYY sorted by date:

    01/02/1903 02/01/1903 01/02/2003 02/01/2003

    So alphabetic and date ordering are different for DD/MM/YYYY

    MM/DD/YYYY sorted alphabetically:

    01/02/1903 02/01/1903 01/02/2003 02/01/2003

    MM/DD/YYYY sorted by date:

    01/02/1903 02/01/1903 01/02/2003 02/01/2003

    So alphabetic and date ordering are the same for MM/DD/YYYY

    WTF don't you understand about this incredibly simple concept?

    I don't understand how 02/01/1903 comes before 01/02/2003 in an alphabetic/numeric sort.

  • Anonymous (unregistered) in reply to Nagesh Kukunoor
    Nagesh Kukunoor:
    I have much to learn from you noble troll. I have been practising hard but you are clearly very experienced.
    Good job, keep up the hard work. But quieten down and we may yet score a few more bites!
  • foo (unregistered) in reply to anon
    anon:
    I don't understand how 02/01/1903 comes before 01/02/2003 in an alphabetic/numeric sort.
    Indeed. The idea was clever, but he wanted too much and messed it up. Good trolling is hard work.
  • Anonymous (unregistered) in reply to foo
    foo:
    anon:
    I don't understand how 02/01/1903 comes before 01/02/2003 in an alphabetic/numeric sort.
    Indeed. The idea was clever, but he wanted too much and messed it up. Good trolling is hard work.
    If he's being serious, he's trying to tell us that MM/DD/YYYY is better than DD/MM/YYYY because it doesn't screw up for sorting within one year, but for sorting in different years it behaves like DD/MM/YYYY, which makes it somehow more universal. In this case he's forgetting however that MM/DD/YYYY confuses people for numerous reasons which I will explain in case there is need for.
  • Tally-Ho (unregistered) in reply to Anonymous
    Anonymous:
    Nagesh Kukunoor:
    I have much to learn from you noble troll. I have been practising hard but you are clearly very experienced.
    Good job, keep up the hard work. But quieten down and we may yet score a few more bites!

    Make sure you tally those totals, you enormous looser.

  • Bert Glanstron (unregistered) in reply to Anonymous
    Anonymous:
    Nagesh Kukunoor:
    I have much to learn from you noble troll. I have been practising hard but you are clearly very experienced.
    Good job, keep up the hard work. But quieten down and we may yet score a few more bites!
    Well, nice played! But doing this as "Your Name=Anonymous" only deserves one answer:

    In case you can’t tell, this is a grown-up place. The fact that you insist on using your ridiculous handle clearly shows that you’re too young and too stupid to be trolling TDWTF.

    Go away and grow up.

    Sincerely, Bert Glanstron

  • Curious George (unregistered) in reply to Sudo
    Sudo:
    I DESPISE variable names like myVar or similar... they're the comic sans of variable names.
    Are you the clown that refactored all the source because "you didn't like the var names", now making it impossible to troubleshoot significant issues?
  • Curious George (unregistered) in reply to Andrew
    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.

    +1

    Yeah, every dev & admin at every vendor working crazy to get out the Y2K certified software (with the latest gee-whiz that marketing wanted, natch), with every dev & admin at every end site working crazy to test, install, verify & patch both the vendors crap & their own Kustom Krap.

    Made good money but it was a lost year.

  • Sudo (unregistered)

    In an attempt to solve this issue, I propose the following date format be adopted:

    D

    Start counting from day 0 (presumably the day that time came into existence, for backwards compatibility). Scrap the notions of years and months entirely, because they're obviously confusing us all greatly. Make sure to store it as a suitably large integer type.

    The average man on the street would hate it, but life would be peachy for developers.

  • Curious George (unregistered)

    Note, class, todays trollers managed to riff off of two of todays themes:

    Proper date validation Valid unit tests

    For bonus points, identify which concepts apply to each argument.

  • db (unregistered) in reply to SCSimmons
    SCSimmons:

    (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.)

    I got hit by a Y2K bug in January 2008 in a freshly released version of the Macrovision flexlm/flexnet software. That stopped us from running some quite expensive software for a week because our perpetual licence was identified as expiring on 1/1/2000. I've got no idea what the hell they were thinking. The first helpdesk guy didn't even know what a Y2K bug was.

  • Sudo (unregistered) in reply to Curious George
    Curious George:
    Sudo:
    I DESPISE variable names like myVar or similar... they're the comic sans of variable names.
    Are you the clown that refactored all the source because "you didn't like the var names", now making it impossible to troubleshoot significant issues?
    Interesting reasoning. I also despise small dogs, but I've never attempted to kill one...
  • Biggles (unregistered) in reply to SCSimmons
    SCSimmons:
    .... I have a reminder in my calendar for 3/1/2013 to verify that my fix actually works correctly in production. :)
    Couldn't you fudge some data and change the date on a dev box to test it?
    SCSimmons:
    (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.)

    Probably either "I won't be here come 2000" or "WOW, this 2000 bug is really overrated"

  • Spike (unregistered) in reply to SCSimmons
    SCSimmons:

    ...

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

    ...

    wow, either your an idiot or a troll!

  • (cs) in reply to Biggles
    Biggles:
    SCSimmons:
    .... I have a reminder in my calendar for 3/1/2013 to verify that my fix actually works correctly in production. :)
    Couldn't you fudge some data and change the date on a dev box to test it?
    Oh, I did that. Worked fine in the development environment, so I'm not really expecting any problems. I'm just a belt + suspenders + another belt kind of person these days.
    Biggles:
    SCSimmons:
    (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.)
    Probably either "I won't be here come 2000" or "WOW, this 2000 bug is really overrated"
    He may have been thinking the same thing I was when I made the ugly quick-fix of adding a century offset to the two-digit year (the application now handled dates between 1950 and 2049): "This company will be out of business by the time this turns into a problem." He was a little too pessimistic--I was fully correct, which is why I don't work there anymore either. (This was one of the companies profiled in "About the Billion-Dollar Lessons: What You Can Learn from the Most Inexcusable Business Failures of the Last 25 Years" by Paul B. Carroll, a book I was made aware of at this site, and which I was highly amused to learn had posted the moldering corpse of my previous employer as a warning to others. I took the severance package & ran in 2002, even though my manager thought he could get me a transfer to another division after my position was eliminated, as any rat could tell that the ship was sinking.)
    Spike:
    SCSimmons:
    I have a reminder in my calendar for 3/1/2013 to verify that my fix actually works correctly in production. :)
    wow, either your an idiot or a troll!
    Why can't I be both? Or even, why can't both of us be both?
  • Ken B. (unregistered) in reply to DCRoss
    DCRoss:
    Ken B.:
    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.)
    Oh, did you work for DEC^WCompaq^WHP^WWhatever-they're-called-today?

    http://h71000.www7.hp.com/openvms/products/year-2000/leap.html

    Nope. While I have worked on VAXen, this is simply a case of our software having the same "bug" as them.

    Our reply, however, was not quite so loquacious. It was basically "not a bug -- the year 2000 is a leap year".

  • Ken B. (unregistered) in reply to SCSimmons
    SCSimmons:
    He may have been thinking the same thing I was when I made the ugly quick-fix of adding a century offset to the two-digit year (the application now handled dates between 1950 and 2049)
    You do realize that someone actually got a patent for that "invention". (US Patent number 5,806,063.)
  • (cs) in reply to Ken B.
    Ken B.:
    SCSimmons:
    He may have been thinking the same thing I was when I made the ugly quick-fix of adding a century offset to the two-digit year (the application now handled dates between 1950 and 2049)
    You do realize that someone actually got a patent for that "invention". (US Patent number 5,806,063.)
    Wow. I guess somebody owes someone some royalties ...
  • mulli (unregistered) in reply to FuBar
    FuBar:
    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.
    Yeah, well. People are trying to prevent them.

    As for maturity. The problem isn't the engineering. It's the management. They hire incompetent and unskilled workers for what is essentially a field for experts. And should there be an actual expert trying to do his job they are actively ignoring the expertise and doing their best to undermine and subvert all sensible approaches and solutions.

    So, if there is an appearance on immaturity in the field, it's because the people who could do something about it are locked in the playpen.

  • secundum (unregistered) in reply to Gilbert
    Gilbert:
    Tim:
    note for US citizens: other countries really do exist, and some of them even have computers
    OK you correctly identified a couple top problems
    1. The US exists
    2. They have computers

    but you missed

    1. Graphical interfaces let people who have no business touching computers think they can

    FTFY

  • Jeff (unregistered)

    "Fix a couple of reports displaying “19100” here and correct some validation logic there"

    Says you. I was coding for DOS and with 512k of memory available (himem was a POS) I had to modularize multiple forms because adding the first two digits of years caused them to just barely cross the threshold.

    I spent 6 months of 50+ hour days fixing one application in my company's arsenal.

  • unknown user (unregistered)

    I never wrote VB, but I have a question. Is there any kind of explanation why somebody would write something like this:

        For i = 0 To Len (thisDate) - 1
            thisChar = Left (thisDate, i + 1)
            thisChar = Right (thisChar, 1)
    

    Might 'Left' have a sideeffect on thisDate?

  • anon (unregistered) in reply to Brendan

    Maybe that's how Obama will solve the unemployment problem.

  • Gio (unregistered) in reply to Matthew

    This is the most flexible way to do it.

  • Ouch! (unregistered) in reply to unknown user
    unknown user:
    I never wrote VB, but I have a question. Is there any kind of explanation why somebody would write something like this:
        For i = 0 To Len (thisDate) - 1
            thisChar = Left (thisDate, i + 1)
            thisChar = Right (thisChar, 1)
    
    Might 'Left' have a sideeffect on thisDate?
    They don't know how to spell 'Mid'? Or that might be faster than
     thisChar = Mid(thisDate,i,1) 
    (but I'd be surprised).

    Also, they didn't know they could get the Char with

    thisDate(i)
    I've never written VB either, but it took me all of five minutes to find that out. I guess there might be a reason for the reputation of VB.

  • (cs) in reply to SCSimmons
    SCSimmons:
    (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.)

    I can do you one better. In 1999 Q4, I fixed about a half dozen Y2K bugs in scripts written in 1999 Q2-4. The developer was still around, and didn't get fired over it. He also didn't get fired over the Y2K bugs in scripts he wrote in 2000. And, yes, he did put scripts into production in the year 2000 which claimed the current year was 1900. Fortunately, he did voluntarily leave in 2000.

    His reasoning was that this was the way he always did it, and it always worked before, so the fact it wasn't working now was an OS defect. This despite the fact he was at multiple meetings where we said, "Stop using {bad code example}. Use {good code example} instead." Fortunately, his scripts actually used the bad code example character for character, so it was generally pretty easy to fix it.

  • (cs) in reply to FuBar
    FuBar:
    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.

    Personally, I'd hope that it gets professionalized around 29 years from now. Of course, I understand, this is my own pipe dream - there'll probably be enough 64 bit or more computers that 2038 will be a mitigated disaster, rather than a true catastrophe.

    (Yes, I know, 64 bit computing will fix a lot of the 2038 bug issues. However, my suspicion is, the primary effect of this will be to prevent management from permitting the programming resources needed to fix this, so most of the bugs that will still be there on January 1, 2030 will still be there on January 19, 2038. We will therefore actually get to feel them, and there will be companies that crumble because of them.)

  • Anonymous (unregistered)

    FUCK OFF CINDY WE DON'T WANT YOUR SPAM!

  • A. Meiburg (unregistered)

    It's comforting to know that the date

    00010/000030/100

    is still valid.

Leave a comment on “Annual Y2K”

Log In or post as a guest

Replying to comment #:

« Return to Article