Comment On Validating a Date with a Sledgehammer

Man, that is ugly.

It's amazing that so many WTFs come from date handling code. Why must people reinvent the wheel so poorly so many times?

Ummm, did I miss it or does this awesome validation method forget about leap years? As far as I can see, Feb must never have more than 28 days!?! Poor leap years, no one ever loved them enough to validate them.

if (dday > "28" && mmnth == "02" )
{
alert("wrong number of days in specified MONTH default value set")
userdate.value = ddate1
userdate.focus()
return (false)
}

Indeed, this doesn't work for leap years. And it's.. err.. horrible.

Now try to imagine the additional 10k lines of code to handle other date formats like YYYY-MM-DD...

Even <script language="JavaScript"> isn't valid.

TRWTF is that Date.getMonth() is apparently zero-indexed... why??

Anyway, Javascript validation is completely useless.

Can anyone tell me where I need to go to get a job writing pointless date validation routines all day? We see soooo many on TDWTF and to be honest, I'm a bit annoyed that in my job I'm expected to use the built-in functions and then get on with something more important.

Not that I want to defend this code, but a read-only field+ datetimepicker can be less user-friendly... sometimes it's much more productive to do data entry by manually keying in the data, rather than moving the mouse around to select the proper value.
What I'm saying is that Catherine's solution is not "obviously better", it's just simpler and less bug-prone :)

posit9 > "9"

Does anyone else see anything just a bit hilarious with that line?

How many single characters are greater than 9?

Did the user enter the shorthand for infinity into a date field? Or perhaps he was just checking for Roman Numerals...?

The more important question is how much you're get pay'd for.
If you want such a Job - go ahead, for $10 a month you can write it for me, I'll post hear :-)

KD:

Can anyone tell me where I need to go to get a job writing pointless date validation routines all day?

Probably the same place where you get a job writing pointless TheDailyWTF comments all day.

Well, at least it's commented and indented!

Isn't is about time we decimalised time?

1 s = 1 second
1 ks = 1000 seconds (16 mins 40 secs)
1 Ms = 1e6 seconds (11 days 13 hours 46 minutes 40 seconds)

etc...

DaveAronson:

KD:

Can anyone tell me where I need to go to get a job writing pointless date validation routines all day?

Probably the same place where you get a job writing pointless TheDailyWTF comments all day.

Well, I've sort of got that job already but I'm actually expected to turn in some real work between writing pointless TheDailyWTF comments. I'd like to be able to write pointless TheDailyWTF comments and then turn in a pointless date validation routine. Whilst getting paid my current senior developer wage. Hmm, I think this is a lost cause to be honest...

Indeed, for some incredibly naive coding and general bad design, the documentation is better than most WELL written production code!

charlie:

Well, at least it's commented and indented!

The lack of semicolons makes my eyes bleed.

Which shows that bad coders comment...

Go see an eye doctor.

We often unroll regular expressions to address speed and reliability concerns, especially in languages like Javascript. The real WTF here is that the developer didn't construct a javascript state machine to evaluate the string. That's the standard method of unrolling regular expressions.

My bad. >_< Read that wrong. It's Monday.

@Alex: And also, the DELETE button is broken. >_<

The real wtf is using alert.

Jok:

Anyway, Javascript validation is completely useless.

Javascript validation is by no means useless - it is a perfectly good way of giving the user fast feedback on easily-checked errors. If you meant that doing validation only in Javascript is useless, well then I could agree with you.

There's already such a thing. Ever heard of Swatch's internet beats.

Only time I ever saw them in use however was on my high school math exam...

The older you get, the less productive they become. Because it takes an extra click each year to get from the default current date to your birthdate.

Thankfully, in her submission Catherine reported that this bit of of code was retired and replaced by a read-only field populated by a date-picker and a two-line if(...) alert(...) vet.

Yay! I'm sure that works perfectly without Javascript enabled. Let's have a big hand for barrier-free web design! :)

Jok:

Anyway, Javascript validation is completely useless.

No, it's not. Client-side validation is as mandatory as server-side validation. You should make your interface as friendly as possible and tell the nice user that he typed something you're not going to accept and on the big, bad servers you should stab the user that tried to get around your client validation or simply doesn't have JS enabled on his/her client.
Why submit a whole page to your server just to send it back pre-populated? I hate it when I have to submit a form and if I make a mistake (usually not pointed out because the designer forgets to add a comment next to a field) I just get an almost-blank page saying "username is invalid, try again." Then I have to click <-Back and refill the form, because their brilliant HTTP expiry headers made my browser reload the whole page. Sometimes, I get the same form, pre-populated, just informing me of what I did wrong and I have to re-type my password twice to send it, because it won't send the password back to me (usually it's encrypted on the client before it's sent, so it CAN'T and that's a good thing). Sometimes it forgets to warn me that I didn't re-type my [quite long] password and I have to check the form again and submit it again... DAMN, THAT'S ANNOYING!

To all web developers out there and in here: STOP DOING THAT! Use some basic client-side validation, use Ajax (in the name of all the gods, there are thousands of libraries implementing simple Ajax calls) to verify some of the data and, if the page needs to be displayed again, re-populate it and warn me about WHAT is wrong and WHAT should be done. You lazy asses... I know it takes twice as much work but it also doubles the usability and your users will stay with you twice as long and recommend it to twice as many friends.

Is it really that difficult to be nice to your users which are, in fact, your customers? Even if you're offering your shiny, expensive, given-by-Zeus knowledge, they offer you something in return, too. Don't think that you're the only one giving them something. By coming to YOUR site, they're also doing YOU a favor. Don't just throw out some crumbs and expect people to eat them off the floor; give them a nice table and put some butter on that bread and they will tell everyone about you. By visiting your website (even if you're giving something away for free), you gain their respect and you earn yourself a name BECAUSE PEOPLE STICK AROUND YOU. So if you want people to stick around you, there's only one thing you have to do: BE NICE TO THEM. Appreciate that they're using your free services, don't just expect appreciation in return.

If the user isn't knowledgeable enough, don't just tell him that he's stupid. Let him know that he did something wrong, something you weren't prepared for (theoretically it's your fault) and offer him some coffee while he thinks how to fix whatever is wrong with his input. If the users see a clean interface, they will stick a lot longer with you. The age of the "here's how I did it, now give me recognition and do it yourself" is over. There are more and more nice people out there that not only share knowledge but also share kindness and your users will run away to them. NOTHING YOU DO IN THE BENEFIT OF THE USER IS USELESS. Everything will pay off, maybe not in a month, not in a year, but it will, in a few years. I know, you have to pay your rent NOW but the users don't care about that because they have THEIR own rent to pay NOW. Have you ever thought about that?

JavaScript validation is useful.

Graham Stewart :

TRWTF is that Date.getMonth() is apparently zero-indexed... why??

Because arrays, at least in .Net, are zero-indexed ofcourse, eg. ArrayofMonthNames[d.GetMonth()]

The goggles! They do nothing!

Simply brillant!

Mike5

DidIMissIt:

Ummm, did I miss it or does this awesome validation method forget about leap years? As far as I can see, Feb must never have more than 28 days!?! Poor leap years, no one ever loved them enough to validate them.

if (dday > "28" && mmnth == "02" )
{
alert("wrong number of days in specified MONTH default value set")
userdate.value = ddate1
userdate.focus()
return (false)
}

Whenever you see people just adding numbers to dates, you've got a WTF. In practical terms, if you don't have a date object that maintains the calendar separate from the time, you're up a creek...I can't think of a popular language that doesn't have one. Javascripts is the Date() object, and to get a future date you just do something like:

var myDate=new Date();
myDate.setDate(myDate.getDate()+5);

Which will return today + 5 days. So if the user puts in a valid day, lets call it userDay, and we have the current day toDay, we can simply compare them with:

if(userDay<toDay){do stuff}

The day validation is the hard part. Not being a javascript junkie, I don't know if this would work, but I'd just take the date from the input box, and try to cram it into a date object inside a try/catch block. It should choke on a bad date, though depending on the implementation you might get some unexpected results. It's easier than doing the month/day comparison stuff though.

Oooh oooh! I get to make the first witty comment where I make fun of the code and use it to say my comment!

But I'm not going to. Ha.

Also: whoever wrote this better have learned javascript from a For Dummies book. Jeesh.

Nick J:

Isn't is about time we decimalised time?
1 s = 1 second
1 ks = 1000 seconds (16 mins 40 secs)
1 Ms = 1e6 seconds (11 days 13 hours 46 minutes 40 seconds)
etc...

Good idea! It works well for milliseconds and microseconds.

Yeah, I wondered the same thing about all the checks like:

if (posit1 < "0")

Would love to see how you encode negativity into a single text field char.

Will:

The more important question is how much you're get pay'd for.
If you want such a Job - go ahead, for $10 a month you can write it for me, I'll post hear :-)

Is "pay'd" even a word?

//--- THIS COMMENT WAS DESIGNED BY ----//
//--- DAVE------- ON 12/15/2008 -----//

Seriously, that's an indication that neither TONY B or his supervisors had no clue what version control was.

Anonymous coward:

Graham Stewart :

TRWTF is that Date.getMonth() is apparently zero-indexed... why??

Because arrays, at least in .Net, are zero-indexed ofcourse, eg. ArrayofMonthNames[d.GetMonth()]

Well yeah, but that's not really a very good reason though is it?
If I set the date as February then I'd expect the month to be two, not one.

I mean isn't it less of a leap to just do:

ArrayofMonthNames[d.GetMonth() - 1]

Than to have:

mydate = new Date("25/01/1975")

year = mydate.getFullYear()  // 1975

day = mydate.getDate()       // 25

month = mydate.getMonth()    // 0 ?!

As you say, .NET arrays are zero-indexed, but in .NET the month of January is still 1 (System.DateTime.Month).

Surely the:

if (x < "0") ...

checks perform string comparison, thus making sure the characters are in fact digits and nothing else... don't they?

rohypnol:

* clip start of rant *
Sometimes, I get the same form, pre-populated, just informing me of what I did wrong and I have to re-type my password twice to send it, because it won't send the password back to me (usually it's encrypted on the client before it's sent, so it CAN'T and that's a good thing).
* clip end of rant *

Come again? What client-side encryption is done on password fields that would prevent the HTTP server sending that data back to the browser?

And once again, the "preview" of the article takes up fully 1/2 of the front page of the site.

fred34:

Indeed, for some incredibly naive coding and general bad design, the documentation is better than most WELL written production code!

Well written production code doesn't need any comments.

If your code NEEDS lots of comments, then it NEEDS re-writing.
If you NEED comments to understand code, then you NEED to learn how to code.

Off topic but if Alex is reading can you please use this formatting for all future code posts?
It is the first time I have had code formatting maintain line breaks in my RSS reader.

Mr B:

fred34:

Indeed, for some incredibly naive coding and general bad design, the documentation is better than most WELL written production code!

Well written production code doesn't need any comments.

If your code NEEDS lots of comments, then it NEEDS re-writing.
If you NEED comments to understand code, then you NEED to learn how to code.

I code in pure ASM. I use a lot of comments. Do I have got to do it again sir?

The only real WTF is the apparent lack of comprehensive unit tests. The problem with leap years, for example, is only possible because the coder didn't write his tests first.

In a very real sense, I don't care how gnarly the code is, as long as it's well tested. Why should I have to look inside the date validation code at all? It should be an opaque box to me... One in which I have confidence because it's well tested.

I'd also like to echo a previous poster's observation that replacing this code with drop downs is not necessarily an improvement. Sure it makes life easier on the coder, but it possibly does so at the expense of the user. It's hard to imagine the universe in which that's a good trade off.

It's starting to bother me that we WTF posters are more concerned with nitpicking lousy code than with the bad practices (or absence of good practices) that make it possible. Lousy code is no longer entertaining to me, and I don't think I'm learning much from it.

rohypnol:

Jok:

Anyway, Javascript validation is completely useless.

No, it's not. Client-side validation is as mandatory as server-side validation. You should make your interface as friendly as blah blah blah blah blah...
JavaScript validation is useful.

I do not provide the teeming masses with tools because I want to be "friendly", but rather because it amuses me, much as it amuses me when my parrot pretends to read the newspaper I line his cage with.
If the hoi polloi want the knowledge and the wisdom I provide, then they can show their appreciation and obeisance by entering data as I instruct them to. If they are incapable of so doing, they can leave as ignorant as they came.

Another WTF is that "this bit of of code was retired and replaced by a read-only field populated by a date-picker". Considering that most (all?) date-pickers are programmed in JavaScript, I won't be able to manually enter a date into read-only field if I have JS turned off?

TDD Chauvinist:

The only real WTF is the apparent lack of comprehensive unit tests. The problem with leap years, for example, is only possible because the coder didn't write his tests first.

In a very real sense, I don't care how gnarly the code is, as long as it's well tested. Why should I have to look inside the date validation code at all? It should be an opaque box to me... One in which I have confidence because it's well tested.

I'd also like to echo a previous poster's observation that replacing this code with drop downs is not necessarily an improvement. Sure it makes life easier on the coder, but it possibly does so at the expense of the user. It's hard to imagine the universe in which that's a good trade off.

It's starting to bother me that we WTF posters are more concerned with nitpicking lousy code than with the bad practices (or absence of good practices) that make it possible. Lousy code is no longer entertaining to me, and I don't think I'm learning much from it.

I appreciate your point of view and it may well be fair to say that implementing good practices is more important than writing good code (after all, bad code can be replaced but a bad practice is ingrained into your development process). However, it seems a bit silly to me to use this as vindication for today's SOD. You make out as if unit tests would have fixed the 'leap year' problem but this is only true if the coder had of coded a unit test that exercises it properly. And if the coder in question doesn't even know about the Date class, then how the hell is he going to be able to write comprehensive unit tests to exercise every single code path in his routine(s)?

And even if the whole thing was fully unit tested and worked - would that really make it any better to you? Would that excuse the total lack of comprehension shown by the coder in question? Would that somehow buy back all the wasted CPU cycles caused by this useless date validation routine?

Again, I see your point but I don't think this is really the time to champion TDD. All this code needs is a decent code review. Then someone with a better understanding of JavaScript can point out the Date object to this coder.

Date pickers (mouse only) are horrible inefficient compared to using the keyboard. Sites that force you to click dozens or more times to get to the right year, then more clicks to get to the right month, just to pick a date are very unfriendly.

Almost every form that requires a date also requires keyboard entry also (first name, etc), so why do these genius UI people think that it is somehow more friendly to force the user to click on the mouse 30-50 times to pick a birthdate, rather than just type it in? Do we need first name and last name pickers? Is it that hard to type???

Even worse are US State pickers... having to go through a whole drop-down list when I could just type TWO LETTERS.

UGH WTF.

Phill:

Off topic but if Alex is reading can you please use this formatting for all future code posts?
It is the first time I have had code formatting maintain line breaks in my RSS reader.

I second this comment.

Well today's code is exactly the reason why I tend to do a two stage verification of date inputs:

A simple JavaScript regular expression to make sure the format is ok (for instance yyyy-dd-mm) to catch the most obvious user blunders like substituting a / for a - or similar and then a server side check using a parametrized sql query or similar to catch the rest.

I usually say, that things like time and date manipulation you should never do yourself but use the language / database build-in functions!

Yours Yazeran

Plan: To go to mars one day with a hammer

Captcha: delenit - A deleted rock???

Anonymous:

Mr B:

fred34:

Indeed, for some incredibly naive coding and general bad design, the documentation is better than most WELL written production code!

Well written production code doesn't need any comments.

If your code NEEDS lots of comments, then it NEEDS re-writing.
If you NEED comments to understand code, then you NEED to learn how to code.

I code in pure ASM. I use a lot of comments. Do I have got to do it again sir?

Yup, sorry, even in ASM if you need comments in the code, then the code needs re-writing. The pseudo-logic for ASM belongs outside codebase comments. If someone handed me ASM with comments but no pseudo-code I'd throw it back at them.

Note that my gripe was with "comments" not "documentation", and the sort of comments I usually see with ASM coders are along the lines of:

Label1:
mov ax, bx ;we move bx into ax
add ax, bx ;add the contents of bx into ax
...

Yup, that's really adding value there! Adding about the same amount of value as:

//--- get first character of date make sure its less than 4 ---//
posit0 = userdate.value.charAt(0)
if (posit0 < "0" || posit0 > "3")

When it's checking if it's less than 0 or greater than 4, rather than it being less than 4. So the comments don't actually match the code anyway, marvellous!