When is your birthDate, your birthString and your birt/hStr/ings ?

  • "Please check why the birth date is not appearing in the page"

    Hey, that bug seems pretty easy to solve... let's go for it! Checkout, compile, run, navigate, verify the page is not showing the birth date.

    Time to dig into the code... and voilá! I found the place where the bean is loaded. Set breakpoint, run again, navigate again, reach the breakpoint. Step into. The query seems right. Step out. The birth date has been retrieved right and set into the dBirthDate field (a java.util.Date). But wait... the bean has dBirthDate and strBirthDate... and the second one is null...


    Compile again, run again, navigate once more, verify the page is finally showing the birth date.

    But just curios about that "duality", I go back in the code and the fields strDayBirthDate, strMonthBirthDate and strYearBirthDate suddenly reveal themselves... so we have one field to store the date, one field to store the formatted date, and three fields to store the day, the month and the year. Wondering about the misterious usage that could have lead to this, I search for references to theirs setters... This is the WTF-ish piece of code I found:

    Fragment of the SELECT query: 
        d.D_BIRTH_DATE birthDate,
        to_char(nvl(d.D_BIRTH_DATE,''), 'dd') day,
        to_char(nvl(d.D_BIRTH_DATE,''), 'mm') month,
        to_char(nvl(d.D_BIRTH_DATE,''), 'yyyy') year,
    Fragment of the code:
    Even more curious is that the INSERT and UPDATE queries (located in the same class) are using the strBirthDate...
    Leasons learned: you can have up to three different birth dates! at the same time!! with just one bean to represent you!!!
    As "extra points" for WTF, this is the beginning of our utility methods to parse dates:
    public static final Date parse(final String string) {
      if ((string == null) || (string.length() == 0)) {
        return null;
      if ((string.length() < 8) || string.contains("null")) { // Avoids "15//" "15/null/1915" and similar inputs
        return null;

  • Oh you crazy wtfers make me laugh.  You make my work day yo. 

  • I love the month of null.  The weather is so beautiful.

  • Definite WTF, but I've seen it before. Often this is done when the recieving application doesn't have a correct representation of a Date object. Most languages have that now, so I bet you're looking at a very old piece of legacy code. The stored procedure was designed to support an old language, and rather than update the proc, they just did a work-around to accept the old-style 'split-up' date format. Years ago (late 90s), I worked on a database that is from the 70s, and there's 3 columns for the date... month, day and a two-digit year! Rather than fix the database, the applications that use the data have all kinds of work-arounds... even worse, the database is still fed from flat cobol files that use the same format, so the scope of a project that would fix this major WTF, is huge and expensive involving multiple companies. The fixes wouldn't be horrible (you could just fix the date during loads), but they would affect multiple applications currently using the work-around, and pretty much the management decided it's not worth it to fix the issue until 2049, when the two digit year thing will cause major havoc and there will be no way to work around it. C'est la vie :)


  • @jasmine2501 said:

    so I bet you're looking at a very old piece of legacy code

    It has been coded last month... (language is Java 1.4.2, and the database is Oracle)

  • @theNestruo said:

    (language is Java 1.4.2, and the database is Oracle)

    Bet it's Oracle 9i, too (current version is 11g IIRC).  Why upgrade when all this old stuff works? 

Log in to reply

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.