Oh, dates. Oh, dates in Java. They’re a bit of a dangerous mess, at least prior to Java 8. That’s why Java 8 created its own date-time libraries, and why JodaTime was the gold standard in Java date handling for many years.

But it doesn’t really matter what date handling you do if you’re TRWTF. An Anonymous submitter passed along this method, which is meant to set the start and end date of a search range, based on a number of days:

private void setRange(int days){
        DateFormat df = new SimpleDateFormat("yyyy-MM-dd")
        Date d = new Date();
        Calendar c = Calendar.getInstance()
        c.setTime(d);

        Date start =  c.getTime();

        if(days==-1){
                c.add(Calendar.DAY_OF_MONTH, -1);
                assertThat(c.getTime()).isNotEqualTo(start)
        }
        else if(days==-7){
                c.add(Calendar.DAY_OF_MONTH, -7)
                assertThat(c.getTime()).isNotEqualTo(start)
        }
        else if (days==-30){
                c.add(Calendar.DAY_OF_MONTH, -30)
                assertThat(c.getTime()).isNotEqualTo(start)
        }
        else if (days==-365){
                c.add(Calendar.DAY_OF_MONTH, -365)
                assertThat(c.getTime()).isNotEqualTo(start)
        }

        from = df.format(start).toString()+"T07:00:00.000Z"
        to = df.format(d).toString()+"T07:00:00.000Z"
}

Right off the bat, days only has a handful of valid values- a day, a week, a month(ish) or a year(ish). I’m sure passing it as an int would never cause any confusion. The fact that they don’t quite grasp what variables are for is a nice touch. I’m also quite fond of how they declare a date format at the top, but then also want to append a hard-coded timezone to the format, which again, I’m sure will never cause any confusion or issues. The assertThat calls check that the Calendar.add method does what it’s documented to do, making those both pointless and stupid.

But that’s all small stuff. The real magic is that they never actually use the calendar after adding/subtracting dates. They obviously meant to include d = c.getTime() someplace, but forgot. Then, without actually testing the code (they have so many asserts, why would they need to test?) they checked it in. It wasn’t until QA was checking the prerelease build that anyone noticed, “Hey, filtering by dates doesn’t work,” and an investigation revealed that from and to always had the same value.

[Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!