• Brian Boorman (google)

    int frist=-1; setRange (frist);

  • RLB (unregistered)

    Jodatime. Not to be confused, of course, with Yodatime, a.k.a. the way Merkins write dates.

  • bvs23bkv33 (unregistered)

    int main() {
    exec sql SELECT TO_DATE('2000-01-02', 'YYYY-MM-DD') - TO_DATE('2000-01-01', 'YYYY-MM-DD') AS DateDiff FROM dual;
    }

  • (nodebb)

    Just love this!!

    This was in code heading for production. Thank God the QAs got there first. The assertThat method is part of the JUnit unit testing framework. So now production code needs a dependancy upon a unit test framework for a production deployment.

    Unless that is how they deploy to production.

    Brett

  • Chris L (unregistered)

    Prerelease is usually the best time to find serious bug(s). Especially when you enjoy working till 2am.

  • Ashley Sheridan (unregistered)

    Is Yodatime the same as American format, given that the fields are in the wrong order? :P

  • I Am A Robot (unregistered)

    So QA saw a bug in performance and returned the code? And we're seeing the code before it was fixed? This doesn't really seem to be a WTF, rather it's the system working as it should.

  • DrPepper (unregistered)

    And properly written unit tests would have caught the error long before it got out of the branch, let alone into pre-production code. Always, always write unit tests.

  • I Saw a Robot (unregistered) in reply to I Am A Robot

    Code that doesn't pass QA isn't necessarily a WTF. Code that doesn't pass because it's braindead IS a WTF.

  • Not a Merkin (unregistered)

    Aside from being pointless the asserts don't even check that the date functions work correctly, just that they returned something that was different from the original value

  • löchlein deluxe (unregistered)

    Well, the assertions show that somebody had set out to fix that bug already and then the phone rang, in all likelyhood.

  • Merkin Robot (unregistered)

    Since the input parameter is the actual value subtracted, everything can be reduced to a single if.

    If (days==-1 || days==-7 || days==-30 || days==-365) { c.add(Calendar.DAY_OF_MONTH, days); }

    Still hurts on all other sides though.

  • Little Bobby Tables (unregistered)

    Nobody's commented on the negative nature of the "days" variable. It adds another level of complexity that seems to me to be unnecessary.

  • Queex (unregistered)

    I think the assert statements were put in at some point as a passive-aggressive defence of the code.

    "You say that to and from are the same? I'll put in assert statements and PROVE they're not! Checkmate!"

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    But isn't this what they mean by test-driven development? We don't just run tests at build time, we run them ALL THE TIME!

    assertThat(to).isNotEqualTo(from)

    Oops, missed one.

  • Jarcionek (unregistered)

    I think it can be simplified slightly...

    private void setRange(int days) { DateFormat df = new SimpleDateFormat("yyyy-MM-dd");

    Calendar c = Calendar.getInstance();
c.add(Calendar.DAY_OF_MONTH, days);

from = df.format(new Date()) + "T07:00:00.000Z";
to = df.format(c.getTime()) + "T07:00:00.000Z";

    }

    Of course depending whether 'days' is positive or negative, 'from' can be before or after 'to', but we don't know the actual requirements.

  • anonymous (unregistered)

    TRWTF is that they're using a Calendar but just modifying DAY_OF_MONTH. For an offset of "one month" or "one year", Calendar already handles this properly by setting MONTH or YEAR, and the result will actually be a month or a year instead of an approximation.

  • akozakie (unregistered)

    What an optimistic WTF! Yeah, sure, braindead code... but look, they actually HAVE QA! And it kinda works! Wow!

    They will probably drop out of the market soon. That's not cost-effective. Clients can do the testing, and you don't have to pay them - everybody knows that. ;-)

Leave a comment on “The Same Date”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article