JavaScript Dates in Other Countries

[Thomas 'PointedEars' Lahn]

Making up your own bizarre definitions for common terms is only going to
create confusion.

Nothing was made up. Words can acquire several meanings over time; that was
pointed out. And if anything is authoritative on the meanings of the term
"hack", it is the Jargon File written and maintained by one of the greatest
hackers of our time. <DM>Sheesh.</DM>


PointedEars

 

[Thomas 'PointedEars' Lahn]

Ask yourself why they have to write that. Something is wrong with the your
interface or your API, *that* is what you need to fix.

Below is an altered version that allows you to set the month names
appropriately, based upon what I suggested below and upon some of
Thomas Lahn's suggestions.

I am glad that you have not considered adding a copyright notice; I would
not want to be associated with such junk (as a whole; no offense meant).

CompareTwoDates = (function() {
var englishMonthNames = ["January", "February", "March",
"April", "May", "June", "July", "August", "September", "October",
"November", "December"];
var monthNames;
var result = function(firstDate,secondDate,operator) {
var tmp;
// ConparisonType eg. <,>,= etc
tmp=firstDate.split(" ");

The initialization can be done in the declaration statement; no need for
duplicates.

firstDate=tmp[0]+" "+(monthNames[tmp[1].toLowerCase()] ||
tmp[1])+" "+tmp[2]

This is unreadable; have you ever heard of Pretty Printing? A semicolon at
the end is missing, too; optional, but recommended to put it there.

var fdate=Date.parse(firstDate);
var sdate=Date.parse(secondDate);
var ret=false;

if (isNaN(fdate)) return "Error. First argument is not a
Date";
if (isNaN(sdate)) return "Error. Second argument is not a
Date";

eval("if (fdate"+operator+"sdate) { ret=true; }");

I do know it was not your idea, but you reviewed this code, and it is still
full of Really Bad Ideas. You *really* do not want to do any of the former
three lines to begin with.

You want to throw an exception (or return a constant exit code if `throw'
is not supported) and, if it cannot be avoided to pass a string for the
operand (which is also a Bad Idea because it is expensive and error-prone)
where a number would suffice, at least switch-case-default on the string
argument instead. i18n can take care of the error message then.

And instead of mapping localized names to English names, should you not be
mapping localized month names to month numbers instead to save further
expensive and error-prone date string parsing (ES3, 15.9.4.2: "Date.parse
is implementation-dependent when given any string value that could not be
produced in that implementation by the toString or toUTCString method.";
ES5, 15.9.4.2: "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. Unrecognizable Strings or dates containing illegal
element values in the format String shall cause Date.parse to return
NaN.")?

result.setMonthNames = function(newVals) {
if (newVals.length != 12) {
return "Error. There must be twelve month names";
}

Given this assertion, ...

monthNames = {};

.... why create a new object on every call at all?


PointedEars

 

[Scott Sauyet]

I am glad that you have not considered adding a copyright notice; I would
not want to be associated with such junk (as a whole; no offense meant).

No offense taken. I made it pretty clear that I didn't want any
responsibility for the original code. So did the OP, who has to
update someone else's code. I intentionally made as few changes as
possible to the original function, keeping not just the API but as
much of the implementation as possible. Mine was really little more
than a wrapper to the original function which added the ability to
alter the month names.

    CompareTwoDates = (function() {
        var englishMonthNames = ["January", "February", // ...
        var monthNames;
        var result = function(firstDate,secondDate,operator) {
            var tmp;
            // ConparisonType eg. <,>,= etc
            tmp=firstDate.split(" ");

The initialization can be done in the declaration statement; no need for
duplicates.
Yes.

            firstDate=tmp[0]+" "+(monthNames[tmp[1].toLowerCase()] ||
tmp[1])+" "+tmp[2]

This is unreadable; have you ever heard of Pretty Printing?  A semicolon at
the end is missing, too; optional, but recommended to put it there.

This is a result of the minimal changes. I would not code it in this
manner at all.

I do know it was not your idea, but you reviewed this code, and it is still
full of Really Bad Ideas.  You *really* do not want to do any of the former
three lines to begin with.

I don't want any of it, honestly. But I don't know how much work it
would be for the OP to update the interface exposed.

And instead of mapping localized names to English names, should you not be
mapping localized month names to month numbers instead to save further
expensive and error-prone date string parsing [ ... ]?

Yes, if you're making larger changes to the implementation than I was
willing to do.

Given this assertion, ...


... why create a new object on every call at all?

I don't follow. This is created only on the call to
CompareTwoDates.setMonthNames(), which would presumably happen once
(for English) or twice (for other languages) per page visit. The
whole point of that call is to reset the monthNames variable used in
the main function with a new object. Am I missing something?

-- Scott

 

[David Mark]

If you're referring to this post

   http://groups.google.com/group/comp.lang.javascript/msg/eab3be4c311689c4

then I beg to differ.  When you claimed, "I certainly don't "watch"
any jQuery lists.

And I don't. Neither do you have any evidence that I do.

And I never trumpet anything in here," I pointed to
five separate threads you'd initiated in the past month.

I know. I was happy for that, but it is hard to imagine that you
are now bragging about it.

Each of
those initial posts involved a critique of jQuery.

I know. I wrote them.

Four of them
referred directly to posts in the jQuery forum.

Yes. And most (if not all) were responses to comments in _other
threads_ (e.g. by Matt Kruse). See where you fucked up in your beady-
eyed determination to look clever?

I am not citing random nonsense that does not support my position.  In
fact, I've stated no position on this matter.

Your implied position was clear. And it is rather irritating when
people post links with no explanation at all.

I simply supplied some
evidence that your statement was incorrect.

But it wasn't evidence of that at all (see above).

As to the other matter, how long does one have to hang out here to be
allowed to act as a smart-ass?

When they have gained enough knowledge to actually act smart.

Because I'd much rather do that than
act like some of the dumb-asses that have been posting here for a
longer time.

LOL. Oh, you got me. You must be a treat in real life.

Rather, quoting one of the best-known authorities on hacking might
help settle some confusion.

Not really. You posted two contradictory samples and I was using the
word hack to describe _people_ (starting with the incompetent imbecile
who authored the page in question).

I am trying to learn it better.  That's what I'm doing in these parts.

Then stick to that and stop wasting my time with slightly-off
arguments.

A worthless link is still better than attempting a serious rebuttal of
a rhetorical flourish such as the first sentence of the following

Like this one.

| Remember that Javascript is a hack.  It's an elegant hack, and can
be
| a very nice language to work in, but it was thrown together fairly
| quickly, copied, then standardized without nearly as much thought as
| often goes into other languages.  Internationalization was not a
major
| consideration.  Don't get me wrong, I really enjoy working in JS,
but
| it has a number of warts.

with something like this:

| Javascript is not a hack.  Lots of hacks attempt to write it (and
| write about it), but they don't define the language.

Posting that seems fairly worthless.  It doesn't doesn't rebut,
refine, or elaborate the substance of the paragraph it was responding
to.

Sure it does. Perhaps you should write it a hundred times.

It picks out one word, and makes what is essentially a pun on
that word, and responds to the altered meaning of that one word.  That
is pure sophism.  (Or there is some sort of language barrier in play?)

Could be? Is English your first language? ISTM I asked you that once
before.

I shouldn't have responded.  But I didn't want the nonsense you
supplied to be the last word on that subject.



None of this has anything to do with helping the OP address his
problem.

Again with the slightly skewed logic. I was, of course, referring to
the discussion I was having with you about JS being a "hack".

The paragraph to which you responded was at least an attempt
to explain *why* the problem existed.

I don't think it explained anything of the sort.

Do you really claim that your
"not a hack" comment added something of value to the discussion?

See above.

No, the one commonly used among programmers, is probably a good
start.  Do you know what that is?

Sure do. Who doesn't? And clearly the JS language is not one.

Excuse me.  Is your ego really large enough to think that your usage
of the word is what matters when you were the one who jumped in to say
that my usage was incorrect?

Again, just off-center enough to waste my time. You know that wasn't
what I meant.

No wonder you think your library and
your putative book deal are so much better than any other JS sources
that exist.

And there you go again, drawing conclusions from a flawed hypothesis.
And here's a news flash for you, my library is easily the most
influential and innovative giant-blob-of-browser-scripting ever
published. So I'd lay off of it. And I've never mentioned any "book
deal" here, so you must be imagining things again.

 

[David Mark]

Nothing was made up.  Words can acquire several meanings over time; that was
pointed out.

And what definition would make "hack" appropriate to describe the JS
language?

And if anything is authoritative on the meanings of the term
"hack", it is the Jargon File written and maintained by one of the greatest
hackers of our time.  <DM>Sheesh.</DM>

Oh screw him and his page. Hacker is a pejorative where I come
from.

 

[Laser Lips]

Sorry Thomas but what on earth are you talking about. They enter
dates into an input box as "01 Gennaio 2009".
They enter is like that because they are Italian.

Scott, I have tested this by remote desk toping to an Italian sever
and running the code in the intended system.
I used a browser on the Italian server which was obviously running in
Italy so when running alert(new Date().toLocaleString()); I receive a
date with Italian months in the Italian format.

Using toLocaleString does not yield the same date string format from
country to country, which is where the function getMonthIndex() comes
in.
It will not cause an error (Thomas) because Im using JavaScript to get
the months. The only 'VARIABLE' which can change throughout the whole
thing is the initial input and if it's incorrect then the validation
will fail, likes it's supposed to. End of

Graham

 

[Thomas 'PointedEars' Lahn]

And what definition would make "hack" appropriate to describe the JS
language?

IMHO, it was quite a clever thing to do (and a one-man show) developing
a Java-like scripting language for the Web, but not necessarily thought
through; we can still observe the repercussions today.


PointedEars

 

[David Mark]

IMHO, it was quite a clever thing to do (and a one-man show) developing
a Java-like scripting language for the Web, but not necessarily thought
through; we can still observe the repercussions today.

Yes, clever. But I don't equate clever with hacking. Hacks are Bad
Things. And certainly the language is imperfect, but calling it a
"hack" smacks of the usual "JS is broken" nonsense that is used to
justify crappy libraries. Get it? Could have done without all of the
sidetrack "arguing".

 

[Scott Sauyet]

And I don't.  Neither do you have any evidence that I do.

No, but I'll bet my suspicions are shared by most people paying
attention.

[ ... ] And I never trumpet anything in here," I pointed to
five separate threads you'd initiated in the past month.

I know.    I was happy for that, but it is hard to imagine that you
are now bragging about it.

Bragging? No. Simply explaining.

Yes.  And most (if not all) were responses to comments in _other
threads_ (e.g. by Matt Kruse).  See where you fucked up in your beady-
eyed determination to look clever?

I don't believe you. It's kind of sad to doubt someone else's honesty
or motives, but I don't believe that a majority of those posts were
direct responses to links posted in other threads. I'm more than
willing to retract that if you show evidence, but I'll be surprised if
you come up with it.

And what is it with you and Matt Kruse? I don't really know much
about his Javascript chops, but I certainly know that in comparison
with you and your diatribes, Matt is a voice of reason here. Is it
just that he's willing to offer a qualified defense of jQuery, which
-- if your rants are any indication -- must have stolen your
girlfriend or some such? Or is it that Matt is a fellow human being,
and you've never learned to get along with people like that?

Your implied position was clear.  And it is rather irritating when
people post links with no explanation at all.  

Perhaps you'd like to reread those last two sentences again.

And again.

One more time.

Do you see the contradiction yet?

But it wasn't evidence of that at all (see above).

I've supplied evidence. You claim that there is another explanation.
As I said, I'll willingly retract this if you demonstrate that most of
the jQuery forum links you made in the initial posts of those threads
were in fact posted by Matt Kruse or others in earlier threads here.
If not, I think the jury will likely accept my evidence.

When they have gained enough knowledge to actually act smart.  

Then why have you been acting like a smart-ass here so long? You
clearly haven't qualified.

LOL.  Oh, you got me.  You must be a treat in real life.

Generally mild-mannered. Very few people would call me abrasive. And
even here, until this post, I've had little bad to say about anyone or
any particular technology. Yes, I've called you out on
contradictions, but that's as far as it's gone. I'm expecting to
revert to form after this post.

[ ... ]  You posted two contradictory samples and I was using the
word hack to describe _people_ (starting with the incompetent imbecile
who authored the page in question).

Again, do you realize that I introduced the word "hack" here, and it's
I who've been defending its use. The fact that you tried to switch to
discussing people rather than the intended meaning is, as I said, pure
sophism.

Then stick to that and stop wasting my time with slightly-off
arguments.

Sure, as soon as morons stop twisting my meanings.

Like this one.

Which one is that?

Sure it does.  Perhaps you should write it a hundred times.  

Which does it do? Rebut, refine, or elaborate?

It seems to me that all it does is use a different sense of "hack" and
say that JS doesn't match that sense. That's not a rebuttal, a
refinement, or an elaboration, as far as I can tell.

Could be?  Is English your first language?  ISTM I asked you that once
before.

English is my first language. What's yours?

Yes you have asked that before. I was quoting. I'm glad to see that
your memory is not as far gone as the rest of your mind.

Again with the slightly skewed logic.  I was, of course, referring to
the discussion I was having with you about JS being a "hack".

Again with the extremely skewed logic. So a page that discusses the
meaning of the word "hack" as it is used among hackers was irrelevant
to the discussion about whether JS was a hack? I guess I was being
too charitable when I assumed you meant that "adding to this
discussion" must have had to do with the original poster's issue.

I don't think it explained anything of the sort.

I do.

See above.

Where? I don't see where you claim that your initial post in this
thread added something of value to the discussion.

Sure do.  Who doesn't?  And clearly the JS language is not one.  

Why yes it is. But since you're not actually interested in that
definition, I guess we're not going to come to agreement on this.

Again, just off-center enough to waste my time.  You know that wasn't
what I meant.

That's the only way I could parse your question. What did you mean,
then?

And there you go again, drawing conclusions from a flawed hypothesis.
And here's a news flash for you, my library is easily the most
influential and innovative giant-blob-of-browser-scripting ever
published.  So I'd lay off of it.  

Look as hard as I might, I see no emoticon, no indication of a wink,
no clear-cut evidence that this is not sarcasm or rhetorical
hyperbole. I'm tempted to think that you actually believe this. But
it's hard to imagine that you're quite *that* stupid.

And I've never mentioned any "book
deal" here, so you must be imagining things again.  

I stand corrected. I find no evidence of you mentioning a "book
deal", only a "book", as in this quote [1]:

| > He's said he's writing a book about this stuff,
|
| I am and several samples have already been posted (and appear
| to be quite popular, thank you very much!)

I guess it is hard to imagine a publisher interested in your book,
given the bile you regularly spill here.


Congratulations! You have turned a usually mild-mannered USENET user
into someone who's flaming you for your idiotic behavior online.
That's not an easy feat.

Feel free to have the last word. I won't be responding again, unless
it's to offer a retraction about the source of those posts discussed
above, based on evidence supplied.

-- Scott
____________________
[1] http://groups.google.com/group/comp.lang.javascript/msg/dee45cfe1d5dc965

 

[David Mark]

No, but I'll bet my suspicions are shared by most people paying
attention.

I'm not interested in your suspicions.

*PLONK*

 

[Scott Sauyet]

IMHO, it was quite a clever thing to do (and a one-man show) developing
a Java-like scripting language for the Web, but not necessarily thought
through; we can still observe the repercussions today.

That's exactly what I meant. I think if the language had been thought
through more clearly from the beginning, perhaps there would be better
internationalization incorporated now.

I'm not sure it would have been a good thing if that had happened.
Perhaps it would have been too bloated to catch on, or it would have
lost some of the features that make it so rich now.

As long as we don't devolve to thinking of "hack" as a pejorative, we
can proudly claim that JS is an elegant hack.

-- Scott

 

[Scott Sauyet]

Sorry Thomas but what on earth are you talking about.  They enter
dates into an input box as "01 Gennaio 2009".
They enter is like that because they are Italian.

I don't want to speak for Thomas, but I know that if I were rewriting
this interface, I would try to use a datepicker of some sort, or
require input in a format easier to parse, such as "dd-mm-yyyy" or, if
the users were willing, "yyyy-mm-dd". I had the impression you didn't
have the luxury of making such changes though. If you do, there are
much better techniques.

Scott, I have tested this by remote desk toping to an Italian sever
and running the code in the intended system.
I used a browser on the Italian server which was obviously running in
Italy so when running alert(new Date().toLocaleString()); I receive a
date with Italian months in the Italian format.

Yeah, I finally realized that toLocaleString() goes to the underlying
OS, no matter how your browser is set. That's not something I really
want to mess with.

Again, good luck on your project.

-- Scott

 

[Thomas 'PointedEars' Lahn]

Christian Kirsch wrote:

[quotation levels fixed]

Am 7.1.10 23:14, schrieb Laser Lips:

I rest my case

Non sequitur.

You could provide them with
[...]
- any other UI you can think of that is less error prone than having
users enter strings correctly

All three methods work for Italians, Germans and possibly even Chinese
alike. You might have to tweek it a bit for different calendars like in
Thailand.

My thinking exactly.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Yes, clever. But I don't equate clever with hacking.

YMMV, hence the clarification.

Hacks are Bad Things.
NAK

And certainly the language is imperfect, but calling it a
"hack" smacks of the usual "JS is broken" nonsense that is used to
justify crappy libraries. Get it?

Only if you ignore the *original*, equally common, positive connotation.
ISTM that is even harder to see for you as you are taking this library
business personally.

Could have done without all of the sidetrack "arguing".

Well, you started it, so don't complain now.


PointedEars

 

[Eric Bednarz]

[…] And if anything is authoritative on the meanings of the term
"hack", it is the Jargon File written and maintained by one of the greatest
hackers of our time.

WTF? The jargon file was not ‘written by’ its current maintainer (who,
by some other people, is considered one of the greatest fruitcakes of
our time).

C.f. <http://www.dourish.com/goodies/jargon.html>

 

[Thomas 'PointedEars' Lahn]

[…] And if anything is authoritative on the meanings of the term
"hack", it is the Jargon File written and maintained by one of the
greatest hackers of our time.

WTF? The jargon file was not ‘written by’ its current maintainer

So much the better.


PointedEars

 

[Laser Lips]

I don't want to speak for Thomas, but I know that if I were rewriting
this interface, I would try to use a datepicker of some sort, or
require input in a format easier to parse, such as "dd-mm-yyyy" or, if
the users were willing, "yyyy-mm-dd". I had the impression you didn't
have the luxury of making such changes though. If you do, there are
much better techniques.

But I wonder if you've thought this through entirely. What happens if
run in the U.S., where traditional date formats are more like "January
6, 2010"?

All dates can be entered using the keyboard or a date picker.
One thing I did not mention (which probably should have) was that
firstly when the onblur is called the date is evaluated and turned
into a string of "dd MMM yyyy" format.

So a user could enter
1 January 2009 which will be turned into 01 January 2009
01012009 > 01 January 2009
1 jan 2009 > 01 January 2009
01 jan 2009 > 01 January 2009
01-01-2009 > 01 January 2009
01/01/2009 > 01 January 2009

So what ever the user enters, as long as it's correct, it always gets
turned into the "dd MMM yyyy" format.

I have just logged into a US server and tested the functions, and hey
presto, it works.

Graham

 

[Laser Lips]

Am 8.1.10 11:27, schrieb Laser Lips:



I wonder how you figure out if
  01-02-2009
means "February 1, 2009" (German format and possibly other countries,
too) or "January 2, 2009" (US format)

The system (backend) handles the formating because it know ehere it
is.

I bet. There's not much room for misinterpretation in 1-1-2009.

Cocky sod.

Why is this news group full of twats trying to look clever?

 

[Thomas 'PointedEars' Lahn]

Scott Sauyet posted:

No problem, if new Date or Date.parse is used; one just translates the
alphabetical string (it might be possible, but would be grossly
unreasonable. to do that with a Google Translate call) since JavaScript
implementations are tolerant of field order provided that the day,
month, year substrings can be identified from their content.

JavaScript implementations do not matter; ECMAScript implementations
(*among them*, JavaScript) do. It is unwise to rely on implementation-
dependent behavior; such code is error-prone and not even remotely
future-proof.

Example: Was ES 3 (which claims to standardize implementation behavior as
of 2000 CE) only specifying that implementation-depent behavior for
Date.parse() was only conforming if the format would not match the format
of the return value of Date.prototype.toString() or
Date.prototype.toUTCString(), ES 5 (which claims to standardize
implementation behavior as of 2009) now specifies that any format that does
not match the Date Time String Format of section 15.9.1.14 or that format
which Date.prototype.toString() or Date.prototype.toISOString() return may
trigger implementation-dependent behavior.

(Obviously, Date.parse("January 6, 2010") is supposed to trigger
implementation-dependent behavior everywhere.)


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <bc516abf-d1ae-4c3d-847d-4eafbb473f75@z4
1g2000yqz.googlegroups.com>, Thu, 7 Jan 2010 08:30:00, Laser Lips
<[email protected]> posted:

You have omitted the attribution and the quotation of the essence of
that to which you are responding, thereby causing annoyance.

Dates going in as YYYY-MM-DD would be Ideal and in fact users are able
to put these in. The problem is after the input box looses focus, the
input (YYYY-MM-DD) gets turned into a string representation e.g. "01
Gennaio 2010", and then that's when CompareTwoDates get's called.

x

Show how that happens, and you can be told what you are doing wrong
there.

Users are able to enter dates in a number of different ways e.g.
121209 which will be evaluated to “12 December 2009â€

You have missed the point. Users should be required to enter the date
as three numbers, representing in that order year month and day. It's
not essential to be rigorous about separator characters or field widths.

Never rely on examples in which any two of the day, month, and year
numbers are equal. And ensure that you test with day-of-month below and
above the range 12 to 30.

If you allow 121209 for 12th Dec '09, you'll probably be given 11110 for
11 Jan '10 AND for 1 Nov '10. To be internationally sage, require one
of the ISO 8601 formats : YYYY-MM-DD or YYYYMMDD.

OK I’ve finally come up with a global solution that will work in most
languages, so long as the input format is “dd MMM yyyyâ€

Utter folly. Require something more like yyyy mm dd. Use only numeric
dates in data processing, and use only the order Y M D.

function CompareTwoDates(firstDate,secondDate,operator)
{
var localMonths=[];
if(operator=="=")operator="==";

var englishMonth=Array
("January","February","March","April","May","June","July","August","Sep
tember","October","November","December");

Do not allow your posting agent to wrap code. Write it within a
72-character margin. Code posted must be executable as transmitted.
Many of us would use an array literal there : M = ["", ..., ""] .

var d=new Date(),temp;

NEVER use new Date() when the current date/time is not needed. Using
new Date(0) executes faster (unimportant) and protects against
occasional errors occurring on specific days of the year.

var mIndex=getMonthIndex();
//create an array of localised months
for(x=0;x<12;x++)
{
d.setMonth(x);

Consider D = new Date("2010/01/31")
D.setMonth(1) // Feb
D // will be March 3rd.

temp=d.toLocaleString();

You should never trust any system Date to String routine unless it gives
you full control of the format. Read ECMA 262.

temp=temp.split(" ");
temp=temp[mIndex].toUpperCase();
localMonths[temp]=x;
}

var d=new Date();
var tmp=firstDate.split(" ");
//turn days into an int (removes leading zero's)

x
You should learn to write English before you try to learn JavaScript.

//turn days into an int (removes leading zero's) zeroes
tmp[0]++;tmp[0]--;
d.setDate(tmp[0]);
var tmonth=tmp[1];

d.setMonth(localMonths[tmonth.toUpperCase()]);

If the date set just above is the 31st and the month attempted next is
Feb Apr Jun Sep Nov, you will not get what you probably expect.

Be aware that setFullYear can be given three arguments.

d.setFullYear(tmp[2]);
//recreate the date in english format
secondDate=d.getDate()+" "+englishMonth[d.getMonth()]+"
"+d.getFullYear();

// ConparisonType eg.<,>,= etc
var fdate=Date.parse(firstDate);
var sdate=Date.parse(secondDate);
var ret=false;
if (isNaN(fdate)) return "Error. First argument is not a Date";
if (isNaN(sdate)) return "Error. Second argument is not a Date";
eval("if (fdate"+operator+"sdate) { ret=true; }");

Ugh. Normal practice is for a comparison routine to return positive,
zero, or negative (often +1 0 -1); the relational operator is then
outside the routine. Also, you don't understand the proper use of
Booleans. Read the newsgroup FAQ about 'eval'. Code is more readable
if operators are bounded by whitespace.

In code using that routine, hoe do you propose to distinguish between an
invalid date and a successful comparison ?

return ret;
}

while(hasSpace==true)

You still don't understand Booleans.

alert(CompareTwoDates("02 March 2010","02 March 2010","<"))
// If your in Italiy
// alert(CompareTwoDates("02 Marzo 2010","02 Marzo 2010","<"))
// If your in French
// alert(CompareTwoDates("02 Mars 2010","02 Mars 2010","<"))
// If your in Germany
// alert(CompareTwoDates("02 März 2010","02 März 2010","<"))

Never work in a country that you cannot spell correctly. Those "your"
should be "you're". Remember - while some of the foreigners here wrote
excellent English and will recognise all your errors, there are others
who are still trying to learn English. Do not mislead them.

With your coding abilities, you will need to test your code with all
possible inputs. Your organisation should be advised to employ a well-
trained programmer to do your work.