Comment On The Lesser Date

Ok, he doesn't know you can compare dates like that in whatever language that Jared knows well. But isn't TRWTF that dates are passed around in strings?

TGV:

Ok, he doesn't know you can compare dates like that in whatever language that Jared knows well. But isn't TRWTF that dates are passed around in strings?

Especially if the string is milliseconds since 1970.

Also - why does it return "short" when it's using an int in the code?

Knowing the date class, it's probably implemented just about as elegantly anyway.

Delimeter "/" so they are expecting "DD/MM/YYYY" dates.

No date parser?

then one day someone changes the locale...

He should have overloaded the "<" operator, then you could still do it the lazy way and he could still run his code. Everyone wins!

This was probably introduced as a generic Y2K fix. All that money had to go somewhere...

Actually, it looks like the string is dd/mm/yy, given that it's splitting by /. It looks like this is C# (it's not Java, at any rate). So, if he's only given two yy/mm/dd strings, he could do date1 < date2 (technically, the results would be correct by string comparison). However, you'd think that there's some library that would handle this a bit more... elegantly (especially for locales with mm/dd/yy!)

Apart from the name of the function, it doesn't look too bad if you know you are getting the dates in as dd/mm/yyyy strings, and you don't need to validate them.

You can't just test for something like (DateFrom < DateTo), as they're strings.

The alternative would be to use a date parser, but doing something like (IANAJPSPFMFAM):

Date from = new SimpleDateFormat("dd/MM/yyyy".parse(DateFrom);
Date to = new SimpleDateFormat("dd/MM/yyyy".parse(DateTo);
if (from < to) then

is harder to read/write than
if (CompareDate(DateFrom, DateTo) == 1)

His "quick & nasty" parser is also probably going to be quicker to execute as well.

Maybe it could be improved by using enums or -1, 0, 1 for the return value.

Eric Torset:

He should have overloaded the "<" operator, then you could still do it the lazy way and he could still run his code. Everyone wins!

This was probably introduced as a generic Y2K fix. All that money had to go somewhere...

I have a new swimming pool and two SUV's. I filled the swimming pool with fuel, it's only about half way down.

What did you do with your Y2K money?

pscs:

Apart from the name of the function, it doesn't look too bad if you know you are getting the dates in as dd/mm/yyyy strings, and you don't need to validate them.

You can't just test for something like (DateFrom < DateTo), as they're strings.

The alternative would be to use a date parser, but doing something like (IANAJPSPFMFAM):

Date from = new SimpleDateFormat("dd/MM/yyyy".parse(DateFrom);
Date to = new SimpleDateFormat("dd/MM/yyyy".parse(DateTo);
if (from < to) then

is harder to read/write than
if (CompareDate(DateFrom, DateTo) == 1)

His "quick & nasty" parser is also probably going to be quicker to execute as well.

Maybe it could be improved by using enums or -1, 0, 1 for the return value.

It's okay. They aren't using Java either.

Also - like the other less than functions - return the date that was less than, not a code - throw an error if there is an error.

Victor Noble:

  string delim = "/";

...

  delim = "/";

Just in case the delim got bent when all those bits were churning around.

It started as a "|".

A Nonny Mouse:

then one day someone changes the locale...

That's the good thing of this code: it doesn't break when someone changes the locale!

Volmarias:

So, if he's only given two yy/mm/dd strings, he could do date1 < date2 (technically, the results would be correct by string comparison).

Unless they are actually yy/m/d strings (eg 08/7/30) which scuppers that idea.

A reasonable way to do it is either to use a proper (probably inefficient) date parser with idiosyncratic interface (which date parsers usually have), or do something similar to the way he's done it.

(Maybe people are complaining about the "100 days in a month and 10000 days in a year" design decision, but to avoid unnecessary complexity you want a number >=31 for the days in the month, and >=366 for days in a year, and using 100/10000 (a) makes it clear you *haven't* actually got the number of days since an arbitrary point in time, and (b) makes debugging a lot easier, and won't cause any overflow problems for a couple of hundred thousand years).

pscs:

Volmarias:

So, if he's only given two yy/mm/dd strings, he could do date1 < date2 (technically, the results would be correct by string comparison).

Unless they are actually yy/m/d strings (eg 08/7/30) which scuppers that idea.

A reasonable way to do it is either to use a proper (probably inefficient) date parser with idiosyncratic interface (which date parsers usually have), or do something similar to the way he's done it.

(Maybe people are complaining about the "100 days in a month and 10000 days in a year" design decision, but to avoid unnecessary complexity you want a number >=31 for the days in the month, and >=366 for days in a year, and using 100/10000 (a) makes it clear you *haven't* actually got the number of days since an arbitrary point in time, and (b) makes debugging a lot easier, and won't cause any overflow problems for a couple of hundred thousand years).

The date 300/300/300 is valid though. That's a problem - a date format parser would have threw an invalid date exception - you will never know if your dates are in the correct format until you use them as a proper date.

Contractor Khan:

I have a new swimming pool and two SUV's. I filled the swimming pool with fuel, it's only about half way down.

What did you do with your Y2K money?

You filled your pool with fuel? What are you, a slashdot reader? I filled my pool with babes, and they go all the way down!

Sunday Ironfoot:

Correct me if I'm wrong, but isn't the code assuming dates will be in the format DAY/MONTH/YEAR ?

Yes

So need to
a) Make sure locale settings on the deployment server at set to UK/Europe

No - you need to make sure that data is passed to the function in Europe format. If it's stored in a data store in that format, then you DON'T want to use a locale sensitive comparison function.

Hopefully any data store will NOT store the date in the current locale's format, or changing the location of the PC will trash your data, so you choose a fixed date format and you stick to it.

If you know the date is in European format, then use that, DON'T use locale sensitive functions. Maybe that's why he did it this way, the date parser he knew about was locale sensitive, and that would break it if the PC was changed to the USA locale.

Of course, you should probably use a non-locale specific format such as ISO-8601, but if someone else had already decided that the 'project date format' would be European, then that's what you use, and you can't use locale sensitive functions.

Contractor Khan:

The date 300/300/300 is valid though. That's a problem - a date format parser would have threw an invalid date exception - you will never know if your dates are in the correct format until you use them as a proper date.

That's why I said you needed to know you were being passed valid dates. They could already have been validated somewhere else. The function is a date comparison function, not a date validation function.

I just love how it can return 3.

It took a while, but I think I see the problem with this code.

If they ever create a new month with more than 100 days or decide that a year should have more than 100 months it will produce inconsistent results.
The developer really should have thought of that!

pscs:

Contractor Khan:

The date 300/300/300 is valid though. That's a problem - a date format parser would have threw an invalid date exception - you will never know if your dates are in the correct format until you use them as a proper date.

That's why I said you needed to know you were being passed valid dates. They could already have been validated somewhere else. The function is a date comparison function, not a date validation function.

Lazy. I've never seen anything else function that way - things normally validate their own inputs and will throw exceptions if given null values.

I mean, you get a "3" back, what then!?

On a side note dd/mm/yy makes a whole lot more sense than mm/dd/yy... so does the metric system

pscs:

Sunday Ironfoot:

Correct me if I'm wrong, but isn't the code assuming dates will be in the format DAY/MONTH/YEAR ?

Yes

So need to
a) Make sure locale settings on the deployment server at set to UK/Europe

No - you need to make sure that data is passed to the function in Europe format. If it's stored in a data store in that format, then you DON'T want to use a locale sensitive comparison function.

Hopefully any data store will NOT store the date in the current locale's format, or changing the location of the PC will trash your data, so you choose a fixed date format and you stick to it.

If you know the date is in European format, then use that, DON'T use locale sensitive functions. Maybe that's why he did it this way, the date parser he knew about was locale sensitive, and that would break it if the PC was changed to the USA locale.

Of course, you should probably use a non-locale specific format such as ISO-8601, but if someone else had already decided that the 'project date format' would be European, then that's what you use, and you can't use locale sensitive functions.

I couldn't agree more. I have been working with some proprietary equipment (specifically Eurotherm dataloggers) which could be set up to use either EU or US date format in the data files. As it turned out some of your dataloggers had was set up to one and the rest the other format....
The data files exported by the data loggers did not mention if they was in one or the other format, and while it is quite easy to spot errors like trying to parse 12/31/2007 with the pattern DD/MM/YYYY as wrong, the same is not easy with 07/05/2008...... Screwed a lot of my auto-generated graphs pretty good until we got the date format in the dataloggers synchronized.....

Yours Yazeran

Plan: To go to Mars one day with a hammer...

Sunday Ironfoot:

... DAY/MONTH/YEAR ?

So need to
a) Make sure locale settings on the deployment server at set to UK/Europe
b) Make sure other developers who use this code pass in a string date in UK/EU format. ...

Just FYI, it's not called UK/Europe format, it's called Everywhere-That-Isn't-USA format. So technically there's nothing wrong with it. TRWTF is Month/Day/Year.

true wtf is all the comments suggesting dd-mm-yy format.

1. if you want to compare dates as strings you have to do yyyy-mm-dd
2. if there's one thing we should've learned from y2k, it's that storing years in 2 characters is retarded

testx:

true wtf is all the comments suggesting dd-mm-yy format.

1. if you want to compare dates as strings you have to do yyyy-mm-dd
2. if there's one thing we should've learned from y2k, it's that storing years in 2 characters is retarded

It doesn't limit the number of characters. The date could be 2020202/2020202002/202021213 as long as it's "\" separated.

Daniel:

On a side note dd/mm/yy makes a whole lot more sense than mm/dd/yy... so does the metric system

On the other side, yyyy/mm/dd makes even more sense: it compares, sorts correctly, and also happens to be THE ISO STANDARD.

http://en.wikipedia.org/wiki/ISO_Date_Format

(Once you finish bending that delim from "/" to "-")

It never returns 1 or 2.

Adam:

It never returns 1 or 2.

Well, I guess that depends, actually.

I compare dates using a numerical comparison after factoring through the following formula:

H^2 * B / M

H = Hotness of date
B = Base achieved
M = Money spent

Hotness is a subjective scale largely based on age, BMI and facial symmetry.

The real wtf is he forgot to give the Exception in his catch block a name.

captcha: vulputate (Thanks but I'd like my foxes to stay attached to whatever they're attached to.)

Hey hey hey. Don't be so harsh. In the least the dude is returning a short instead of the extremely expensive int a normal .NET compare method would return :-P

NThenUDie:

The real WTF is he's returning an int instead of the correct return enum value for comparison operators

enum LessThanReturnCodes {Unknown, Lesser, GreaterOrEqual, FileNotFound}

The programmer is returning the "C" style comparison values.

Also his approach seems to be perfectly valid if the dates were stored as strings - so the real WTF is that this function was necessary. I would have just converted to Dates and then compared rather than coming up with my own "multipliers" for the components of the date because that would also check that the date was valied (e.g. No "00/00/2008" being passed).

Bruce:

I would have just converted to Dates and then compared rather than coming up with my own "multipliers" for the components of the date because that would also check that the date was valied (e.g. No "00/00/2008" being passed).

This looks to me like one of those functions that was never meant to go outside the class / namespace (package, for us Java bunnies) it was built in, but the developer couldn't figure out the right combination of Access Modifiers to get it just visible enough. "protected internal" should be sacrificed to the greater gods of coding, as far as I'm concerned... ;^)

008:

The real wtf is he forgot to give the Exception in his catch block a name.

Assuming this is C#, he doesn't need to.

Just FYI, it's not called UK/Europe format, it's called Everywhere-That-Isn't-USA format. So technically there's nothing wrong with it. TRWTF is Month/Day/Year.

FYI, you're wrong

code similar to this would be sooo much more awsomer.

using System;

public class CheckDate
{
public int month = -1;
public int day = -1;
public int year = -1;
public string delim = "/";
public CheckDate(Date dtTest)
{
delim = "/";
try
{
delim = "/";
string[] cons = dtTest.Split(delim.ToCharArray());
delim = "/";
year = Convert.ToInt32(cons[2]);
delim = "/";
month = Convert.ToInt32(cons[1]);
delim = "/";
day = Convert.ToInt32(cons[0]);
delim = "/";

}
catch()
{
delim = "/";
; // Don't do anything, it's better to add to the confusion
// by not catching exceptions and not handling them
}
}
public static bool operator <(CheckDate c1, CheckDate c2)
{

int intDateFrom = Convert.ToInt32(c1.year) * 10000 +
Convert.ToInt32(c1.month) * 100 +
Convert.ToInt32(c1.day);

delim = "/";
cons = DateTo.Split(delim.ToCharArray());
int intDateTo = Convert.ToInt32(c2.year) * 10000 +
Convert.ToInt32(c2.month) * 100 +
Convert.ToInt32(c2.day);
return (intDateFrom < intDateTo);
}
}
... ...

DateTime TheLesserDate = (new CheckDate(DateFrom) < new CheckDate(DateTo)) ? DateFrom : DateTo;
// The setting the delim here, makes it the awsomest(new CheckDate(DateTime.Now)).delim = "/";

Wow, let's count the problems here:

1. Rewriting a library function (well, sort of);
2. Giving it a nonsensical name (I assume it returns the earliest date, and don't get me started on the the);
3. Using strings instead of DateTimes to represent dates;
4. Not checking for null;
5. Not validating the dates.
6. Assuming a specific locale/format in a public method;
7. Using a variable instead of a const for a constant value ("/").
8. Assigning it the exact same value twice.
9. Using a string and calling ToCharArray() instead of just using a char.
10. Using a completely hare-brained method of actually performing the comparison;
11. Returning something different from what the function name implies (you'd expect it to return one of the dates).
12. Returning magic numbers.
13. Returning magic numbers that don't follow standard conventions (the result should be negative if the left argument is smaller).
14. Wrapping everything in a generic try/catch, and throwing away all information about the error.
15. Making it an instance method instead of a static one (OK, maybe that concept is far too advanced for this caliber of contractor, but still...)

I think this is actually worse than the code I'd expect to see from someone who read "Teach yourself ASP.NET in 21 days." It's more likely that this contractor had never even heard of C# before and literally was flipping through the book for the first time while writing this code.

The Darwin Awards, www.darwinawards.com, has a policy of disallowing events (that would otherwise be worthy) because they are too common. I am starting to think that TDWTF needs to have a similar policy. Starting with broken DIY date/time code. It seems every programmer and their gran tries to do dates by themselves; if we heard about it all here there'd be nothing else.

tl;dr: Too much like this, something different plz kthxbai.

I took my whole team to the laser game. And of course I won.

K&T:

Just FYI, it's not called UK/Europe format, it's called Everywhere-That-Isn't-USA format. So technically there's nothing wrong with it. TRWTF is Month/Day/Year.

FYI, you're wrong

Everywhere that isn't USA, Federated States of Micronesia, Palau or Philippines then?

Seriously Dude:

Daniel:

On a side note dd/mm/yy makes a whole lot more sense than mm/dd/yy... so does the metric system

On the other side, yyyy/mm/dd makes even more sense: it compares, sorts correctly, and also happens to be THE ISO STANDARD.

http://en.wikipedia.org/wiki/ISO_Date_Format

(Once you finish bending that delim from "/" to "-")

+1. Cheers.

another wtf is that you can't read the code.

enum LessThanReturnCodes {Equal, Lesser, Greater, IndexOutOfBoundsException}

K&T:

Just FYI, it's not called UK/Europe format, it's called Everywhere-That-Isn't-USA format. So technically there's nothing wrong with it. TRWTF is Month/Day/Year.

FYI, you're wrong

The other commenter neglected Canada which can be considered practically USA, the Philippines and the unforgettable illustrious Republic of Palau as well as the Federated States of Micronesia.

Don't ever forget about them!

Not american:

The other commenter neglected Canada which can be considered practically USA, the Philippines and the unforgettable illustrious Republic of Palau as well as the Federated States of Micronesia.

Don't ever forget about them!

08.30.07 - Never forget!

(Or was that 07.08.30? Or 08.07.30? Or...)

np: Yello - You Gotta Say Yes To Another Excess (Orb Goes The Weasel Mix) (Auntie Aubrey's Excursions Beyond The Call Of Duty (Disc 2))

JonC:

Everywhere that isn't USA, Federated States of Micronesia, Palau or Philippines then?

Wait a second. As a lifelong American, I'm under the impression that pretty much everywhere is part of the USA. I mean, didn't one of our presidential candidates just make campaign stops in the states of Afghanistan and Germany?

And when they show the weather maps on Tee Vee (AKA Web 0.0) the USA covers about 3/4 of the globe, except for that little tail that heads off toward Mexico or whatever those other places are called.

Contractor Khan:

Lazy. I've never seen anything else function that way - things normally validate their own inputs and will throw exceptions if given null values.

I mean, you get a "3" back, what then!?

3 !!!

what now ?

WHAT NOW??!?

Sunday Ironfoot:

Correct me if I'm wrong, but isn't the code assuming dates will be in the format DAY/MONTH/YEAR ?

So need to
a) Make sure locale settings on the deployment server at set to UK/Europe
b) Make sure other developers who use this code pass in a string date in UK/EU format.

If either condition is not met, then the code won't actually throw any exceptions and will appear to work fine. But it will return inconsistant results, and might not be spotted until much later after deployment.

Brillant!!11

What a bright boy you are.