Check if one date is later then first date

[user]

Hi,

Let's say I have 2 dates in the b/m format:

Date 1 and date 2

How do I check whether Date2 is later than Date 1?


Date1. 21-Nov-2006 09:00:00 PM
Date2. 21-Nov-2006 10:00:00 PM

Please advise.

Thanks.

 

[Randy Webb]

user said the following on 11/27/2006 8:12 AM:

Hi,

Let's say I have 2 dates in the b/m format:

Date 1 and date 2

How do I check whether Date2 is later than Date 1?

Create Date Objects from them and compare them.

 

[user]

user said the following on 11/27/2006 8:12 AM:

Create Date Objects from them and compare them.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Yes. I have tried to use setfullyear() ,etc etc and do compare. But the
problem is time. Are there ways to read in the date format specified
above?

 

[pcx99]

Hi,

Let's say I have 2 dates in the b/m format:

Date 1 and date 2

How do I check whether Date2 is later than Date 1?


Date1. 21-Nov-2006 09:00:00 PM
Date2. 21-Nov-2006 10:00:00 PM

Please advise.

Thanks.

You'll need to get both dates into the date object. The Date object
will actually will parse these if you remove the dashes in the date and
replace it with a space. Assuming you can do that...

var date1 = new Date('21 Nov 2006 09:00:00 PM');
var date2 = new Date('21 Nov 2006 10:00:00 PM');

date1 and date2 now have the total milliseconds since some arbitrary
date back in the 70s. Specifically...

date1: 1,164,164,400,000
date2: 1,164,168,000,000

(you can see this number just by doing a document.write(date1*1), which
will force it to cast it as an int.

Once you have your dates parsed you can simply do if (date2 > date1).
If you're a little paranoid you can force a cast by if ((date2*1) >
(date1*1)).

You can also subtract date2 from date1 and get the exact time in
milliseconds,seconds,minutes, hours, days, weeks, years between the two
values.

Hope that helps.

 

[user]

You'll need to get both dates into the date object. The Date object
will actually will parse these if you remove the dashes in the date and
replace it with a space. Assuming you can do that...

var date1 = new Date('21 Nov 2006 09:00:00 PM');
var date2 = new Date('21 Nov 2006 10:00:00 PM');

date1 and date2 now have the total milliseconds since some arbitrary
date back in the 70s. Specifically...

date1: 1,164,164,400,000
date2: 1,164,168,000,000

(you can see this number just by doing a document.write(date1*1), which
will force it to cast it as an int.

Once you have your dates parsed you can simply do if (date2 > date1).
If you're a little paranoid you can force a cast by if ((date2*1) >
(date1*1)).

You can also subtract date2 from date1 and get the exact time in
milliseconds,seconds,minutes, hours, days, weeks, years between the two
values.

Hope that helps.

Thanks! I wasn't aware that Date() can cast the above format to epoch!

 

[user]

Thanks! I wasn't aware that Date() can cast the above format to epoch!

Hi,

var date1 = new Date(document.form1.date1.value);

document.form1.date1.value is in the time format specified above.

But when i do an alert(date1*1)

it showed me "NaN" instead of integer values.

What did I missed out? Casting?

 

[pcx99]

var date1 = new Date(document.form1.date1.value);

document.form1.date1.value is in the time format specified above.

But when i do an alert(date1*1)

it showed me "NaN" instead of integer values.

What did I missed out? Casting?

You'll need to remove the dashes out of the date value. The parser
handles the date just fine when the date values are separated by spaces
but if you leave the dashes in you'll end up with the type of error you
describe.

 

[stevong]

You'll need to remove the dashes out of the date value. The parser
handles the date just fine when the date values are separated by spaces
but if you leave the dashes in you'll end up with the type of error you
describe.

Hi. This is what i did:

x = (document.form1.date1.value).toString();
x = x.replace('-',' ');
alert(x);

But the value of X i received was:

21 Nov-2006 10:00:00 PM

Only 1 dash is removed. Isnt replace supposed to remove all instances?

 

[stevong]

Hi. This is what i did:

x = (document.form1.date1.value).toString();
x = x.replace('-',' ');
alert(x);

But the value of X i received was:

21 Nov-2006 10:00:00 PM

Only 1 dash is removed. Isnt replace supposed to remove all instances?

Hi.

I got it right this time

I have to use the g flag:

replace(/-/g,' ');

Now it works fine! Thanks!!

 

[Lee]

pcx99 said:

You'll need to get both dates into the date object. The Date object
will actually will parse these if you remove the dashes in the date and
replace it with a space. Assuming you can do that...

var date1 = new Date('21 Nov 2006 09:00:00 PM');
var date2 = new Date('21 Nov 2006 10:00:00 PM');

date1 and date2 now have the total milliseconds since some arbitrary
date back in the 70s. Specifically...

date1: 1,164,164,400,000
date2: 1,164,168,000,000

(you can see this number just by doing a document.write(date1*1), which
will force it to cast it as an int.

Once you have your dates parsed you can simply do if (date2 > date1).
If you're a little paranoid you can force a cast by if ((date2*1) >
(date1*1)).

Back when I was first learning programming, I used a multiplication
to simplify the logic of my code and lost points, because multiplying
was more CPU intensive than all of the lines I had avoided. That's
not really true anymore, but it's still more complicated than needed.

Simpler options include:
( date2.getTime() > date1.getTime() )
( date2-date1 > 0 )
or even simply:
( date2 > date1 )


--

 

[Matt Kruse]

Yes. I have tried to use setfullyear() ,etc etc and do compare. But
the problem is time. Are there ways to read in the date format
specified above?

http://www.JavascriptToolbox.com/lib/date/

Methods are here for reading in any date format, as long as you provide a
format string.
The returned Date objects can then be compared using the isBefore or isAfter
methods added to the Date prototype.

 

[Dr J R Stockton]

In comp.lang.javascript message
???
Eschew quaint abbreviations.

You'll need to get both dates into the date object. The Date object
will actually will parse these if you remove the dashes in the date and
replace it with a space. Assuming you can do that...

var date1 = new Date('21 Nov 2006 09:00:00 PM');
var date2 = new Date('21 Nov 2006 10:00:00 PM');

date1 and date2 now have the total milliseconds since some arbitrary
date back in the 70s. Specifically...

It is not an arbitrary date; it is 1970-01-01 00:00:00 GMT.

date1: 1,164,164,400,000
date2: 1,164,168,000,000

The first figure corresponds to Wed Nov 22 03:00:00 UTC 2006. Evidently
you do not recall that dates are generally assumed by Javascript to be
in the user's time zone using the Summer Time rules currently
appropriate (according to the browser/OS).

(you can see this number just by doing a document.write(date1*1), which
will force it to cast it as an int.

Not to an int, but to a Number. Not a cast, which is a
re-interpretation, rather than a transformation, of a bit pattern. For
the purpose, we deprecate multiplication; use unary +, as per the FAQ.

Once you have your dates parsed you can simply do if (date2 > date1).
If you're a little paranoid you can force a cast by if ((date2*1) > naive

You can also subtract date2 from date1 and get the exact time in
milliseconds,seconds,minutes, hours, days, weeks, years between the two
values.

You forgot months! One can get the exact time in milliseconds (ignoring
Leap Seconds); but "exact" conversion to days weeks months years, all of
which are of variable length, is unrealistic.

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

 

[pcx99]

It is not an arbitrary date; it is 1970-01-01 00:00:00 GMT.

This is an arbitrary date. It is constant but the date itself is
arbitrary. There was no reason to pick that particular date other than
for the fact that at one point in time someone did and it's been a part
of various computer languages that resolve julian dates ever since.

The first figure corresponds to Wed Nov 22 03:00:00 UTC 2006. Evidently
you do not recall that dates are generally assumed by Javascript to be
in the user's time zone using the Summer Time rules currently
appropriate (according to the browser/OS).

Evidently for the problem described it does not matter. Since we're
doing a relative check between two dates it doesn't matter if the user
is in china and the parser is resolving everything to GMT as long as
both dates resolve to the same timezone which they will unless a
time-zone deliberately gets into the mix, which the quaint b/c format
seems not to allow.

Not to an int, but to a Number. Not a cast, which is a
re-interpretation, rather than a transformation, of a bit pattern. For
the purpose, we deprecate multiplication; use unary +, as per the FAQ.

document.write(date1); ----> [object]
document.write(date1*1); --> very long integer.

+ is a concatenation element in javascript and may yield unpredictable
results. * guaranteed the conversion without risking concatenation or
requiring additional elements to contain concatenation which would
increase the complexity.

I will, however, concede that in a formal setting date1.getTime() would
be the best practice.

You forgot months! One can get the exact time in milliseconds (ignoring
Leap Seconds); but "exact" conversion to days weeks months years, all of
which are of variable length, is unrealistic.

I'm sorry but this is wrong. If you have the exact number of
miliseconds between two dates as well as the two original starting and
ending dates you can indeed find the exact number of days, weeks,
months, years and any other element you wish to find. You can test this
for yourself by creating a date object for today, and a date object for
some point in the future (even a future which includes a leap year)
convert both to julian numbers, obtain the difference, add the
difference to the original julian number (today), and you'll find on
inspecting the new date that the date, year, month, etc all match up to
your original future date despite the "inexactness" of dealing with leap
years and all that other stuff.

If the date object is able to find this, it does indeed mean that exact
conversions are exactly what is happening which means if you want the
information badly enough, you will be able to get it from elegant
time/date algorithms right on down to setting up a stash of counters and
marking any changes as you brute force a date object second by second
between the two values.

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

And it's a good idea to not be so concerned with the leaves on the trees
that you get lost in the forest. Just because the answer is not the way
YOU would have done it doesn't mean that it's not a correct or valid
answer, this is especially true when the appeal to authority gets kicked
up to textbooks or, in this case, FAQs.

 

[Randy Webb]

pcx99 said the following on 11/28/2006 5:03 AM:

+ is a concatenation element in javascript and may yield unpredictable
results.

That is simply false.

myString = "123";
myNewString = +myString;
alert(typeof myString);

Do you know of a browser that doesn't give number as the type of
myNewString? Or, can you give an example of where using + to convert
from String to Number will give "unpredictable results"?

 

[pcx99]

pcx99 said the following on 11/28/2006 5:03 AM:



That is simply false.

myString = "123";
myNewString = +myString;
alert(typeof myString);

Do you know of a browser that doesn't give number as the type of
myNewString? Or, can you give an example of where using + to convert
from String to Number will give "unpredictable results"?

document.write(+date1);

Just fine does what we all expect and want. Now, given the tutorial
nature of this subject what if the end user decides to be a little bit
more descriptive with what he types into his editor? I don't know about
you but when I'm following new code my output gets very descriptive.

document.write('example: '+date1);

Not so false is it? In fact the result is no longer a julian integer
but a date string.

Now compare that if the user expands on my original example..

document.write('example: '+date1*1);

Still a julian integer. Using a concatenation character when discussing
new concepts with people introduces unnecessary risk into the discussion
it's as simple as that.

But as I said. I erred in not using datex.getTime() so if you want to
beat me up over something at least pick something that makes sense.

 

[Randy Webb]

pcx99 said the following on 11/28/2006 11:41 AM:

document.write(+date1);

Just fine does what we all expect and want. Now, given the tutorial
nature of this subject what if the end user decides to be a little bit
more descriptive with what he types into his editor? I don't know about
you but when I'm following new code my output gets very descriptive.

document.write('example: '+date1);

document.write('example: ' + (+date1));

+ isn't "unpredictable". What predicts how it will act is how it is used.

Not so false is it? In fact the result is no longer a julian integer
but a date string.
Now compare that if the user expands on my original example..

document.write('example: '+date1*1);

And still an integer in my example as well.

 

[pcx99]

pcx99 said the following on 11/28/2006 11:41 AM:

document.write('example: ' + (+date1));

+ isn't "unpredictable". What predicts how it will act is how it is used.

And still an integer in my example as well.

Yes indeed, I'm well aware of this and was aware of this when I wrote
the example. In the absence of the proper getTime method, using
multiplication was still the better choice since it allowed for
unpredictable behavior by the end user in learning the concept. In
short I used javascript's order of operation to my advantage to enhance
the robustness of the code. As I said in one of the parent posts...
"(multiplication) guaranteed the conversion without risking
concatenation or requiring additional elements to contain concatenation
which would increase the complexity."

And that's all I have to say about that.

 

[Dr J R Stockton]

In comp.lang.javascript message

This is an arbitrary date. It is constant but the date itself is
arbitrary. There was no reason to pick that particular date other than
for the fact that at one point in time someone did and it's been a part
of various computer languages that resolve julian dates ever since.

It is not an arbitrary date; it is a reasonably well-chosen date.

Evidently you do not know the proper meaning of Julian Date. Of course,
you are not alone; IBM do not either. Julian Date is a count of days
from Julian Calendar BC 4713-01-01 12:00:00 GMT.

Evidently for the problem described it does not matter. Since we're
doing a relative check between two dates it doesn't matter if the user
is in china and the parser is resolving everything to GMT as long as
both dates resolve to the same timezone which they will unless a time-
zone deliberately gets into the mix, which the quaint b/c format seems
not to allow.

It does not matter for the user's coding.

It DOES matter that you have, either through carelessness or through
lack of understanding, made a false statement which might deceive
innocent readers of your article.

document.write(date1); ----> [object]

That should give the date as a string, something like
Tue Nov 21 21:00:00 UTC 2006
Did you test your assertion of [object] ?

document.write(date1*1); --> very long integer.

+ is a concatenation element in javascript and may yield unpredictable
results.

Incorrect. It is an addition operator where both operands are Number;
if it has a single argument, it yields a Number; if both operands are
Boolean, it coverts them to Number and adds them. If just one argument
is a String, it converts the other to String and concatenates, If both
are strings, it concatenates. Its results are fully defined by
ECMA-262, and I know of no case in which a reputable recent browser gets
it wrong.

* guaranteed the conversion without risking concatenation or
requiring additional elements to contain concatenation which would
increase the complexity.

No additional elements are required before a unary + ; a space may be
needed to prevent it being half of a ++. Try X = 3-+true for example.

I will, however, concede that in a formal setting date1.getTime() would
be the best practice.

But date1.valueOf() while in fact calling for exactly the same
operation is less likely to be confused by a reader with the concept of
getting the time of day. And unary + is simpler and should be faster.

I'm sorry but this is wrong. If you have the exact number of
miliseconds between two dates as well as the two original starting and
ending dates you can indeed find the exact number of days, weeks,
months, years and any other element you wish to find. You can test
this for yourself by creating a date object for today, and a date
object for some point in the future (even a future which includes a
leap year) convert both to julian numbers, obtain the difference, add
the difference to the original julian number (today), and you'll find
on inspecting the new date that the date, year, month, etc all match up
to your original future date despite the "inexactness" of dealing with
leap years and all that other stuff.

That proves nothing. A reversible conversion is not necessarily a
correct conversion.

And it's a good idea to not be so concerned with the leaves on the
trees that you get lost in the forest. Just because the answer is not
the way YOU would have done it doesn't mean that it's not a correct or
valid answer, this is especially true when the appeal to authority gets
kicked up to textbooks or, in this case, FAQs.

That leaves you with only the resource of appealing to your own
authority or that of the unfortunate who had the task of teaching you.
You should also read ECMA-232.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

document.write('example: ' + (+date1));

The ignorant should be unformed that the inner parentheses above are
computationally superfluous. Some may consider that they aid
legibility.

 

[Randy Webb]

Dr J R Stockton said the following on 11/28/2006 3:36 PM:

In comp.lang.javascript message <[email protected]>,


The ignorant should be unformed that the inner parentheses above are
computationally superfluous.

You should proof read more carefully. I don't expect you to understand
why but the "inner parentheses" are there for a very good reason. And,
they are *not* superfluous. They have a very specific reason for being
there.

Some may consider that they aid legibility.

Among other reasons. But I didn't add them for legibility.