«

Hi, I've got a script, which works with dates.
It compares two dates using an operand to test weather the first date
is '<', '>' or '=' to the second date.
Here it is.

function CompareTwoDates(firstDate,secondDate,operator)
{
var tmp;
// ConparisonType eg. <,>,= etc
// first find out if either date is a datetime stamp
if (firstDate.indexOf(":")!=-1)
{
// we assume there is a time portion to remove
tmp=firstDate.split(" ");
firstDate=tmp[0]+" "+tmp[1]+" "+tmp[2]
}
if (secondDate.indexOf(":")!=-1)
{
// we assume there is a time portion to remove
tmp=secondDate.split(" ");
secondDate=tmp[0]+" "+tmp[1]+" "+tmp[2]
}
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; }");
return ret;

}

USAGE:: alert(CompareTwoDates("01 January 2009","01 January
2010",">"))

Here in the UK it works fine. When I run this on an Italian server I
would expect JavaScript to use it's local settings and use Gennaio
instead of January, but it does not. It appears to continue to use
English Dates.
So my Italians are putting in things like CompareTwoDates("01 Gennaio
2009","01 Gennaio 2010",">") but the function is failing because
javascript does not understand the month Gennaio.

How can I tell JavaScript to use another language?

Thanks,
Graham

On Jan 5, 3:03*pm, Laser Lips <loudsphi...@gmail.com> wrote:
> Hi, I've got a script, which works with dates.
> It compares two dates using an operand to test weather the first date
> is '<', '>' or '=' to the second date.
> Here it is.
>
> function CompareTwoDates(firstDate,secondDate,operator)
> {
> * * * * var tmp;
> * * * * // ConparisonType eg. <,>,= etc
> * * * * // first find out if either date is a datetime stamp
> * * * * if (firstDate.indexOf(":")!=-1)
> * * * * {
> * * * * * * * * // we assume there is a time portion to remove
> * * * * * * * * tmp=firstDate.split(" ");
> * * * * * * * * firstDate=tmp[0]+" "+tmp[1]+" "+tmp[2]
> * * * * }
> * * * * if (secondDate.indexOf(":")!=-1)
> * * * * {
> * * * * * * * * // we assume there is a time portion to remove
> * * * * * * * * tmp=secondDate.split(" ");
> * * * * * * * * secondDate=tmp[0]+" "+tmp[1]+" "+tmp[2]
> * * * * }
> * * * * 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 aDate";
>
> * * * * eval("if (fdate"+operator+"sdate) { ret=true; }");
> * * * * return ret;
>
> }
>
> USAGE:: alert(CompareTwoDates("01 January 2009","01 January
> 2010",">"))
>
> Here in the UK it works fine. When I run this on an Italian server I
> would expect JavaScript to use it's local settings and use Gennaio
> instead of January, but it does not. *It appears to continue to use
> English Dates.
> So my Italians are putting in things like CompareTwoDates("01 Gennaio
> 2009","01 Gennaio 2010",">") but the function is failing because
> javascript does not understand the month Gennaio.
>
> How can I tell JavaScript to use another language?
>
> Thanks,
> Graham

Any help on this?
Cheers,
Graham

On Jan 5, 10:03*am, Laser Lips <loudsphi...@gmail.com> wrote:
> would expect JavaScript to use it's local settings and use Gennaio
> instead of January, but it does not. *It appears to continue to use
> English Dates.
> So my Italians are putting in things like CompareTwoDates("01 Gennaio
> 2009","01 Gennaio 2010",">") but the function is failing because
> javascript does not understand the month Gennaio.
>
> How can I tell JavaScript to use another language?

I may be mistaken, but I don't think you can tell Javascript that. I
think your function will need to do more work. You might start by
adding

CompareTwoDates.monthNames = [
"January", "February", "March", "April", "May", "June",
"July", "August", "September", "October", "November",
"December"];

and then using the index of the month name in this array as part of
your algorithm. (I don't know if you also need "Jan", "Feb", "Mar",
etc. or not, but they would be easy to add.)

Then if it's running somewhere with a different language, you can just
override this array.

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"?

Good luck,

-- Scott

Scott Sauyet wrote:

> Laser Lips wrote:
>> would expect JavaScript to use it's local settings and use Gennaio
>> instead of January, but it does not. It appears to continue to use
>> English Dates.
>> So my Italians are putting in things like CompareTwoDates("01 Gennaio
>> 2009","01 Gennaio 2010",">") but the function is failing because
>> javascript does not understand the month Gennaio.
>>
>> How can I tell JavaScript to use another language?
>
> I may be mistaken, but I don't think you can tell Javascript that. I
> think your function will need to do more work.

And the function needs a lot of work, too.

> You might start by adding
>
> CompareTwoDates.monthNames = [

The function identifier really should not start uppercase here.

> "January", "February", "March", "April", "May", "June",
> "July", "August", "September", "October", "November",
> "December"];
>
> and then using the index of the month name in this array as part of
> your algorithm. (I don't know if you also need "Jan", "Feb", "Mar",
> etc. or not, but they would be easy to add.)

A possibility, but consider the implications. For mapping strings
to numbers is generally more efficient to use an Object instance:

CompareTwoDates.monthNames = {
"January": 0,
"February": 1,
"March": 2,
"April": 3,
"May": 4,
"June": 5,
...
};

Since it is rather tedious and potentially error-prone to do the counting
manually, the following loop can use the mapping nature inherent to all
ECMAScript objects to reuse your array for a map (just make sure no month
is named like a built-in property of Array instances; see also my Map
implementation):

for (var a = CompareTwoDates.monthNames,
i = a.length;
i--
{
a[a[i]] = i;
}

Afterwards a["January"] (or a.January) would result in 0, a["February"] in
1 aso.

(It becomes a bit more complex if you also want to support abbreviations.)

The number can then be passed as second argument to the Date constructor in
order to have date values for the comparison.

However, it would be better if CompareTwoDates (better: compareTwoDates)
would also accept references to two Date instances, and instead of using
the third string argument returned a numeric value `r' indicating the
relation between the two (computed) date values (as it is customary: r < 0
if date1 < date2, r === 0 if date1 == date2, and r > 0 if date1 > date2).
Another misuse of eval() could be avoided that way.

> Then if it's running somewhere with a different language, you can just
> override this array.

ACK

> 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"?

True. However, if there is always a month name or abbreviation, and the
year format is Y2K-safe (i.e., more than two digits), a Regular Expression
can handle the matching.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

Thanks for the responses.
This is legacy code. Stuff written, or should I say thrown together
by god knows who to get something working, so I take no responsibility
for it's ugliness.

I still don't understand why when this code runs on an Italian
browser, it does not understand Italian Months. If I hard code the
values to English months and run the code on the Italian browser, it
works as expected.

I would have thought JavaScript was language specific?

Obviously numerical arrays are the way to go, but this means rolling
this hack out over many environments with many different language
definitions. Not ideal, especially since we don't have locale settings
implemented on the front end yet.

Thanks again.
Graham

On Jan 6, 11:33*am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Scott Sauyet wrote:
>> Laser Lips wrote:
>>> How can I tell JavaScript to use another language?
>
>> I may be mistaken, but I don't think you can tell Javascript that. *I
>> think your function will need to do more work.
>
> And the function needs a lot of work, too.

Agreed. There's a real case to be made for replacing it altogether,
but I don't know the size of the code-base that uses it or the
timeframe for the current changes.

>> You might start by adding
>
>> * * CompareTwoDates.monthNames = [
>
> The function identifier really should not start uppercase here.

Agreed.

>> * * * * "January", "February", "March", "April", "May", "June",
>> * * * * "July", "August", "September", "October", "November",
>> "December"];
>
>> and then using the index of the month name in this array as part of
>> your algorithm. *(I don't know if you also need "Jan", "Feb", "Mar",
>> etc. or not, but they would be easy to add.)
>
> A possibility, but consider the implications. *For mapping strings
> to numbers is generally more efficient to use an Object instance:
>
> [ description of method to more efficiently store the look-ups deleted ]
>
> Afterwards a["January"] (or a.January) would result in 0, a["February"] in
> 1 aso.

This would definitely perform better, but there is a complication in
that it would have to run after every time the list of month names is
updated. If you know that it happens in just one place in your script
and you can run this code afterward, it's fine, but it concerns me
some.

Of course you could add a function to replace the month names instead,
but now we're talking about an even bigger rewrite. (Not that this
function doesn't need it!)


> However, it would be better if CompareTwoDates (better: compareTwoDates)
> would also accept references to two Date instances, and instead of using
> the third string argument returned a numeric value `r' indicating the
> relation between the two (computed) date values (as it is customary: r < 0
> if date1 < date2, r === 0 if date1 == date2, and r > 0 if date1> date2). *
> Another misuse of eval() could be avoided that way.

That's clearly a better API, and it's one that most coders are used to
these days. But the OPs subsequent response makes me wonder how
difficult it would be to make that sort of change.

-- Scott

On Jan 6, 12:08*pm, Laser Lips <loudsphi...@gmail.com> wrote:
> This is legacy code. *Stuff written, or should I say thrown together
> by god knows who to get something working, so I take no responsibility
> for it's ugliness.

Been there, done that. The interface this function provides is not
ideal. If you can change it to one like Thomas Lahn suggested, that
would be your best bet. But that may not be an option. If not, then
some variation of what I suggested, probably with Thomas'
modifications is likely your best bet.


> I would have thought JavaScript was language specific?

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.

> Obviously numerical arrays are the way to go, but this means rolling
> this hack out over many environments with many different language
> definitions. Not ideal, especially since we don't have locale settings
> implemented on the front end yet.

Maybe this will be the impetus for that.

Good luck,

-- Scott

In comp.lang.javascript message <c018407e-03b4-43fa-b385-60a1a5d0ad48@b2
g2000yqi.googlegroups.com>, Tue, 5 Jan 2010 07:03:09, Laser Lips
<> posted:


>Here in the UK it works fine. When I run this on an Italian server

The location of the server has no effect (and all servers should [appear
to] use GMT).

> I
>would expect JavaScript to use it's local settings and use Gennaio
>instead of January, but it does not. It appears to continue to use
>English Dates.

No : American .

The locality does not necessarily correspond to the user's preference.

>So my Italians are putting in things like CompareTwoDates("01 Gennaio
>2009","01 Gennaio 2010",">") but the function is failing because
>javascript does not understand the month Gennaio.
>
>How can I tell JavaScript to use another language?

You tell ALL of your users to enter the date in the form YYYY-MM-DD (ISO
8601), which all users of the Gregorian Calendar with normal
intelligence can do. If time is needed, put that after as hh:mm:ss (no
am/pm). You match that with a RegExp to partly check they've got it
right. Then you compare the inputs as strings.

As long as they are told to give the order Y M D h m s, you can
alternatively do as indicated by

S = "2000 6 9"
M = S.match(/^(\d+)\D+(\d+)\D+(\d+)$/) // rigour optional
D = M[1]*1e4 + M[2]*1e2 + +M[3]

using M[x]||0 for fields not compulsory. Comparison will be arithmetic.

That even works for Julian, Hebrew and Islamic dates expressed with a
numeric month - al long as dates of different natures are not
intercompared.

It's a good idea to read the newsgroup c.l.j and its FAQ. See below.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE7 FF3 Op9 Sf3
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

On Jan 6, 1:06*pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> On Jan 6, 12:08*pm, Laser Lips <loudsphi...@gmail.com> wrote:
>
> > This is legacy code. *Stuff written, or should I say thrown together
> > by god knows who to get something working, so I take no responsibility
> > for it's ugliness.
>
> Been there, done that. *The interface this function provides is not
> ideal. *If you can change it to one like Thomas Lahn suggested, that
> would be your best bet. *But that may not be an option. *If not, then
> some variation of what I suggested, probably with Thomas'
> modifications is likely your best bet.
>
> > I would have thought JavaScript was language specific?
>
> Remember that Javascript is a hack.

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

On Jan 7, 3:52*am, David Mark <dmark.cins...@gmail.com> wrote:
> On Jan 6, 1:06*pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
>> On Jan 6, 12:08*pm, Laser Lips <loudsphi...@gmail.com> wrote:
>>> I would have thought JavaScript was language specific?
>
> > Remember that Javascript is a hack.
>
> Javascript is not a hack. *Lots of hacks attempt to write it (and
> write about it), but they don't define the language.

http://catb.org/~esr/jargon/html/meaning-of-hack.html

-- Scott