HTML code:
<input type="text" id="dateField">

js code:
                var dateValue = new
Date(document.getElementById('dateField').value);
                switch (dateValue) {
                        case '9/25/2012':
                                alert ('case 1 here');
                        {
                          dosomething here..
                        }

                       default:
                             alert("I'm not doing it right");
                  }

Comment:
I've entered the value of "9/25/2012" (of course without quotes) for
the dateField entry, but the case switch returns to default, so, I
guess 9/25/2012  is not the value for a date, then what?

| The JavaScript date is measured in milliseconds since midnight
| 01 January, 1970 UTC.

BTW: you should terminate your case clauses with break, if they are not
otherwise terminated, to avoid a fall-through.

"The function first attempts to parse the format of the String according
to the rules called out in Date Time String Format (15.9.1.15). If the
String does not conform to that format the function may fall back to any
implementation-specific heuristics or implementation-specific date formats."

So the only date-time string format for which Date.parse() is required
to have a defined, implementation-independent meaning is a specific
interchange format defined in the standard. It is a simplification of
the ISO 8601 format, YYYY-MM-DDTHH:mm:ss.sssZ. This is great for
communication between software components, but for most human beings.

In order to reliably convert strings to Date values or vice versa, use a
suitable library that can deal with the formats you want. People have
different recommendations on this. My recommendation is Globalize.js
https://github.com/jquery/globalize
because it makes your code globalization-ready without much extra effort
beyond what is needed to work with some particular format and because
its use (both basic and advanced) is described in my book:
http://www.bytelevelbooks.com/books/global_javascript.html

Why not RTFM? The date object generation is your first problem, your
next one will be the comparison in the case statement.

And RTFM would most likely solve a bunch of your future "problems", too.

The Standard permits, but does not require, entirely implementation-
dependent parsing, after trying 15.9.1.15.

The real world is aware that all or almost all browsers are either
written in America or are written with the US market, and MS IE
compatibility, firmly in mind.

Therefore, not only will the weird US date format be supported, but it
will be AT LEAST as reliable as any other date format.

The best format to use, however, is "2012/09/25".  It has all of the
advantages of ISO 8601 except for compliance, and I don't recall it
failing with new Date() in any browser.  But, if using other code,
beware as treating "09" as Octal Zero.

The OP needs to consider whether the whole of that day should be
matched, and whether the offset from GMT might vary.

If only the "calendar" date is wanted, then it is best to use UTC
methods throughout.

NEVER use new Date() except for the measurement of intervals of time.
Use instead new Date(0), which gives consistent results and ought to be
faster.

Query : What do the "Safari" parts of
<http://www.merlyn.demon.co.uk/js-datex.htm> report when using Safari 6
or higher?

  var d = new Date(2012,9,3)

are entirely consistent in every browser, I see no need to use any other method to create a date object.

Usually a date object is required to be set to a specific value other than the epoch, so what is the benefit to creating the object then setting its value (requireing at least one and maybe two further calls) over creating the object and setting its value in one call?

That format works in every browser that I've tried; no-one has reported
that, in any of my pages, it fails; and I've mentioned it often enough
here without being told of any failures either.  Granted, the ECMA specs
do not *require* it to work.  And it is good to show non-FFF dates to
the chronologically backward.

    <http://jsperf.com/date-constructor-comparison>

It's very slightly faster in FF15 and IE8, very slightly slower in
FF10, and much faster in Chr19, all on WinXPsp3.  It's also much
faster on my Android phone.

But that's not the end of the story.  If you were doing this from
source code, I would grant you that this is a much cleaner way to
construct Dates.  But if you need to construct dates from existing
data, there are other issues to consider.  This:

    var year = 2012, month = 9, day = 3;
    var date = new Date(2012, 9, 3);

is much cleaner than this:

    var year = 2012, month = 9, day = 3;
    var oneIndexedMonth = month + 1;
    var date = new Date(year + "/" + (oneIndexedMonth < 10 ? "0" : "")
+
                   oneIndexedMonth + "/" + (day < 10 ? "0" : "") +
day);

and the performance is much less clear:

    <http://jsperf.com/date-constructor-comparison2>

Here the string-building costs enough to drive the performance well
below that of the multi-parameter constructor technique, at least in
FF and IE.  In Chrome, the single String, even when built this way, is
somewhat faster (some JIT compiling here?), and in Android it's still
substantially faster.

So I don't think the choice is as clear as you suggest, except in the
case that you're constructing a Date object in the source code.

I recall a page of one national laboratory (foreigners) which actually
used three digit years in JavaScript for recent dates ... admittedly in
comment.  They also constricted a date string from the results of
getFullYear, getUTCmonth, ... with amusing results at year rollover.
That code is gone; IIRC they now use Jquery or suchlike.

Does anyone here read Latin?

Tha BBC used 2 character years ["MM"] 12 years ago.

Noli reparare in scripto javano,
quod non ruptus,
nisi causa turpitudinis.

Turpitudo stupiditasque
causae primae erratorum.

Necessitas consilii ad decimexione.

Google translate and Perseus latin dictionary did not find it. I tried a
begins-with search for "decimex" in the Perseus word study tool, and it
also missed. A separate search for "mex" also failed.

Also, a suggestion. I was unsure, before I considered context, about
whether "scripto javano" mean "Java writing" or "JavaScript". A word
like JavaScript that is often written as one word with two capital
letters could be translated to a compound word like "jusurandum".

Latin does not make many ad-hoc compounds, and certainly has no incling
about inword capitalisation, it doesn't consider capitalisation at all.

Java is a multilingual island I frequent, Java, also a seperate language
from Javascript, in javascript seems to come from a type of coffee
[mod-L. coffea] not quite apt for translation.

"scriptum" for script is also a bit stretched.