Comment On Maybe NOT_TODAY

That's not so bad actually, at least it's easily readable.

String checkMe = date.trim();

Why is this here, didn't it already say must be in the format YYYY?MM?DD

The real WTF is that they used fixed-length ints, which will cause this code to become a liability in only a few hundred thousand years.

So obviously booleans are extremely inefficient constructs, and code is infinitely more readable when given:

if (isCurrentDay("2007-20-03").equals("TODAy")) {
...
}

Oh wait...

This code is not that bad. I'm curious why one is being added to currentMonth though.

  int currentMonth = today.get( GregorianCalendar.MONTH ) + 1;

0-based month codes, perhaps?

I'm glad they trust the source of the date string so much, otherwise you've got one dead application because of the NumberFormatException.

Surely you'd convert the String to a Date via a SimpleDateFormat parse() method and pass that into the method, and then you can check it.

public boolean isToday(Date toCheck)
{
Calendar c1 = new GregorianCalendar();
c1.setTime(toCheck);
Calendar c2 = new GregorianCalendar();
return ((c1.YEAR == c2.YEAR) && (c1.MONTH == c2.MONTH) && (c1.DAY_OF_MONTH == c2.DAY_OF_MONTH));
}

Zonkers:

This code is not that bad. I'm curious why one is being added to currentMonth though.

  int currentMonth = today.get( GregorianCalendar.MONTH ) + 1;

I'm gonna take a wild shot in the dark and say that GregorianCalendar.MONTH is zero-based, so probably if the month is January, you get 0, February is 1, etc.

CAPTCHA is scooter, segue anyone?

Zonkers:

This code is not that bad. I'm curious why one is being added to currentMonth though.

  int currentMonth = today.get( GregorianCalendar.MONTH ) + 1;

The month function will return January as 0. Most people would rather call it 1.

At least it's better than FILE_NOT_FOUND

Zonkers:

This code is not that bad. I'm curious why one is being added to currentMonth though.

  int currentMonth = today.get( GregorianCalendar.MONTH ) + 1;

In Java, January is 0.

Hmm there is no checking if the input string has the correct length (10 characters) and if the YYYY, MM and DD characters are digit characters

Using subString on a string that is to short is a ArrayIndexOutOfBoundsException

Using parseInt on a non digit is a NumberFormattingException


A well they probably do catch (Exception e) somewhere in the webserver

Blue

Yay a Java SOD. It's been a while.

Yeah this is butt-ugly - not being aware of StringIndexOutOfBoundsException, NumberFormatExceptions, using a GregorianCalendar directly, blergh, you could forgive.

But result = "TODAY"?

Nice :)

Zonkers:

This code is not that bad. I'm curious why one is being added to currentMonth though.

  int currentMonth = today.get( GregorianCalendar.MONTH ) + 1;

In Java, GregorianCalendar.get(Calendar.MONTH) returns 0..11

snoofle:

Zonkers:

This code is not that bad. I'm curious why one is being added to currentMonth though.

  int currentMonth = today.get( GregorianCalendar.MONTH ) + 1;

In Java, GregorianCalendar.get(Calendar.MONTH) returns 0..11

wtf?!

It is actually pretty awesome how one of the possible return values is "NOT_TODAY" instead of "NOT TODAY". It seems the writer has seen someone use a constant, but didn't quite get the point.

As others, I also fail to see the Real WTF, this code is not that bad at all and certainly it lacks the curious perversion. So it returns a string, that's not so bad. Come on now, the one with the thousands of lines of checksums and ifs and counters was way more wtf than this! This is like wtg, as in what the gosh. Booo todays wtf! Hooray yesterdays wtf!

Look at me! I'm on the internets!:

In Java, January is 0.

Java is a lot like Soviet Russia, isn't it?

htg,
checking static constants will always be true.

I think that's an even bigger wtf.

Yes this one is minor.
It should have accepted a date rather than a string and simply pull the year, month, and day out of it for comparisons then return a boolean true or false.

Wrap this in a call that accepts a string that converts it to a date and calls this and you have a very good piece of reusable code that works as intended.

So he missed a few exceptions, seeing this I think it is safe to assume they are caught somewhere else up the line as this is a deep internal function and may not need to handle it's own errors.

whicker:

snoofle:

Zonkers:

This code is not that bad. I'm curious why one is being added to currentMonth though.

  int currentMonth = today.get( GregorianCalendar.MONTH ) + 1;

In Java, GregorianCalendar.get(Calendar.MONTH) returns 0..11

wtf?!

It makes sense when you think about code like this:

String months[] = {"January", "February" /* etc */ };
String thisMonth = months[i];

This is however no excuse for inflicting it on an API as allegedly high-level as Calendar.

Calendar is a world of WTF.

BlueMoon:

Hmm there is no checking if the input string has the correct length (10 characters) and if the YYYY, MM and DD characters are digit characters

Using subString on a string that is to short is a ArrayIndexOutOfBoundsException

Using parseInt on a non digit is a NumberFormattingException


A well they probably do catch (Exception e) somewhere in the webserver

Blue

Wait a minute - fair is fair: the first line does say ASSUME the format is ...

BlueMoon:

Hmm there is no checking if the input string has the correct length (10 characters) and if the YYYY, MM and DD characters are digit characters

Using subString on a string that is to short is a ArrayIndexOutOfBoundsException

Using parseInt on a non digit is a NumberFormattingException


A well they probably do catch (Exception e) somewhere in the webserver

Blue

We don't get to see the method signature. Perhaps this is a private method and the format is checked prior to passing the input.

Also, the exceptions could be thrown and handled at a higher level, but it's difficult to know without the signature.

Either way, not the cleanest way to do it.

Dates are messed up in Java, it's as if the date class was coded on a Friday afternoon with no thought or peer review. Then they tried to fix it with the Calendar system to actually be useful and consistent, but everyone still uses Date objects at some point.

So instead of a Date object that defaults to UTC that handles its calendar internally, with useful methods and conversions between timezones, we get Calendar, that has fields (in capitals no less) so we can do a lookup via Calendar.get(Calendar.YEAR) rather than Calendar.getYear(), and so on. WTF. (yeah, ignore my code above, it should have been return ((c1.get(Calendar.YEAR) == c2.get(Calendar.YEAR))...). The Java compiler can turn a simple getter method into inline code, but this won't work as I presume internally it has a switch statement in the get(int type) method.

Anyway, mix on the SQL Date, DateTime, etc classes on top, and enjoy Java's time and date handling disfunctionality.

Crint: Yeah, got a bit excited there.

htg:

Dates are messed up in Java, it's as if the date class was coded on a Friday afternoon with no thought or peer review. Then they tried to fix it with the Calendar system to actually be useful and consistent, but everyone still uses Date objects at some point.

So instead of a Date object that defaults to UTC that handles its calendar internally, with useful methods and conversions between timezones, we get Calendar, that has fields (in capitals no less) so we can do a lookup via Calendar.get(Calendar.YEAR) rather than Calendar.getYear(), and so on. WTF. (yeah, ignore my code above, it should have been return ((c1.get(Calendar.YEAR) == c2.get(Calendar.YEAR))...). The Java compiler can turn a simple getter method into inline code, but this won't work as I presume internally it has a switch statement in the get(int type) method.

Anyway, mix on the SQL Date, DateTime, etc classes on top, and enjoy Java's time and date handling disfunctionality.

Actually, the implementation of Calendar uses an array of fields, with the constants (i.e.: Calendar.MONTH) used to index into the array.

In Latin, "Jehovah" begins with an "i".

T$:

That's not so bad actually, at least it's easily readable.

String checkMe = date.trim();

Why is this here, didn't it already say must be in the format YYYY?MM?DD

A user would never put in extra characters or anything.....

If you are dealing with Strings this would work.
getTime() guarantees you get the system date.
format() will return a String.
equals() will not fail, even if it is passed a null, just return false so that protects format errors.

But truth be told, Java Dates are one giant ball of WTF's and that is why the entire API is basically deprecated.

String ret = "NOT_TODAY";
SimpleDateFormat sdf = new SimpleDateFormat("yyyy?MM?dd");
Calendar cal = Calendar.getInstance();
Date today = cal.getTime();
String dateStr = sdf.format(today);
if (dateStr.equals(date)){
ret = "TODAY";
}
return ret;

Hmmm...one line solution?

return IDataUtil.getString( cursor, "date" ).replaceAll("[^0-9]", new String() ).equals( new SimpleDateFormat ("yyyyMMdd").format(  new GregorianCalendar().getTime() ) );

All complete with less hazards than the previous solution.

wick:

Calendar cal = Calendar.getInstance();
Date today = cal.getTime();

Date today = new Date();

Thorin:

T$:

That's not so bad actually, at least it's easily readable.

String checkMe = date.trim();

Why is this here, didn't it already say must be in the format YYYY?MM?DD

A user would never put in extra characters or anything.....

I'm assuming the fact that it said to assume the string coming in was valid and correctly formatted would presume that we don't have to test for it again. Same reason we don't have to walk through the string one character at a time to test that the YYYY MM and DD are numeric.

snoofle:

Zonkers:

This code is not that bad. I'm curious why one is being added to currentMonth though.

  int currentMonth = today.get( GregorianCalendar.MONTH ) + 1;

In Java, GregorianCalendar.get(Calendar.MONTH) returns 0..11

well, it can actually return 12.
You knew that if you read some source files

I suspect that if Calendar were designed post-Java 1.5.0, they would have made things like JANUARY and MONDAY enums instead of ints, to make sure nobody even tries to use them for anything like this.

In Java, code refactors you.

The real WTF is that he is using Strings and numbers taken from the dates instead of using dates directly and using methods such as "DaysBetween" or "Equals"(Not sure about this one)...

it could be a lot more easier this way

rufio:

well, it can actually return 12.
You knew that if you read some source files

You don't need to RTFS, just plain old fashioned RTFM. The javadocs for Calendar state that there is another month UNDECIMBER that comes after DECEMBER.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html#UNDECIMBER

alejo0121:

The real WTF is that he is using Strings and numbers taken from the dates instead of using dates directly and using methods such as "DaysBetween" or "Equals"(Not sure about this one)...

it could be a lot more easier this way

The Real WTF (TM) is people commenting on APIs they know nothing about.

alejo0121:

The real WTF is that he is using Strings and numbers taken from the dates instead of using dates directly and using methods such as "DaysBetween" or "Equals"(Not sure about this one)...

it could be a lot more easier this way

Remember that the Date class isn't just a date; it's a date and time, down to the millisecond. Date.equals() checks the time too, so it would not be appropriate here.

There is no DaysBetween (or daysBetween, or whatever) on the Date class.

There is a small race condition at midnight.
If it is Tuesday with a millisecond to go to Wednesday,
it may be Wednesday by the time the caller gets the result.
Maybe thats okay. Shrug.

But...provided the parse exceptions are handled by the callers, I would not call this a WTF.

It seems inefficient to extract the year, extract the month and extract the day, then get the current year, get the current month and get the current day and then compare them.

Depending on the application, it's probably better to extract the year, get the current year and compare them and return if they're different without looking at the month and day.

If it's more likely that the day will vary, then check that first.

This function is incomplete: other acceptable return values are MAYBE_NOT_TOMORROW and BUT_SOME_DAY.

Shoulda used python.

/evil grin

htg:

Dates are messed up in Java, it's as if the date class was coded on a Friday afternoon with no thought or peer review. Then they tried to fix it with the Calendar system to actually be useful and consistent, but everyone still uses Date objects at some point.

No kidding. I'd forgotten how stupid date handling in Java can be - it's been quite a while since I've written any Java code.

wick:

If you are dealing with Strings this would work.
getTime() guarantees you get the system date.
format() will return a String.
equals() will not fail, even if it is passed a null, just return false so that protects format errors.

But truth be told, Java Dates are one giant ball of WTF's and that is why the entire API is basically deprecated.

String ret = "NOT_TODAY";
SimpleDateFormat sdf = new SimpleDateFormat("yyyy?MM?dd");
Calendar cal = Calendar.getInstance();
Date today = cal.getTime();
String dateStr = sdf.format(today);
if (dateStr.equals(date)){
ret = "TODAY";
}
return ret;

This code will almost always return "NOT_TODAY" unless if statement is run at midnight exactly.

I'm not too sure about using "?" as a wildcard character in the SimpleDateFormat but I have to look that one up.

I THINK this will work...

def isNumber(x):

    try: x+1

        return x

    except TypeError:

        return "switch"



def isToday(checkThisDate):

    myToday=today()

    rawDate=checkThisDate

    nowData=""

    dateList=[]

    for index in range(len(checkThisDate)-1, -1, -1):

        if isNumber(index)=="switch":

              dateList.append(nowData)

        else:

              nowData+=range

    if dateList=today():

        return "TODAY!HUZZAH!"

    else

        dateString="dateList(0)+"/"+dateList(1)+"/"+datelist(2)

        return dateString

Crap. Probably would help to turn the numbers into variables before testing to see if they're numbers, huh?

 ===================

  //input param date must be in format YYYY?MM?DD

  //where ? might be any character

  //returns "TODAY" or "NOT_TODAY"



  String date = IDataUtil.getString( cursor, "date" );

This IDataUtil and cursor variables worry me a bit.

reminds me of fread(FH,...)

Also:
From the java doc

GregorianCalendar is a hybrid calendar that supports both the Julian and Gregorian calendar systems...

Shouldn't it be called JulianAndGregorianCalendar then?

Addendum (2007-03-28 14:41):
How about..

perl -e"print((shift=~m/^`date +%Y.%m.%d`/)?'':q/NOT_/,qq/TODAY\n/)" "2007?03?28"

*ducks*

Er. I mean turn them into integers. I'll go kill myself now if you don't mind.

Er I mean integers. Gah.

Gedoon:

Booo todays wtf! Hooray yesterdays wtf!

Buried for alluding to Red Stripe commercials.