Check if one date is later then first date

[pcx99]

In comp.lang.javascript message

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

Still arbitrarily set. It could have been 01/01/1969 or 10/25/1955,
from a coding perspective there's no difference between the two.

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 you're not aware of the function of Julian dates in the
computer sciences. COBOL uses 01/01/1601. NASA uses 5/24/1968. The
PICK OS used 01/01/1965. Astronomers have their own julian system and
there are various other niche systems. These are all Julian date
systems which represents the passage of time with a simple integer.
There is no single Julian date, there is an original Julian calendar and
there are a plethora of additional Julian systems with different
starting dates. The selection of 1/1/1970 was an arbitrary decision by
the developers of the language, 1/2/1970 would have worked just as well
as far as javascript is concerned.

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.

Not. There's no error with the code. It will parse both dates
perfectly great providing differing time zones are not inserted into the
string being parsed which, given the original data, is not a factor.
Which means the browser's time-zones will be used which means the
relative check between date1 and date2 will be flawless. Even if the
original data originated in a different time zone it still does not
matter because the code is only doing a relative check between the two
dates.

The time zone is simply not a factor in the problem or solution.

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.

This is the relevant part from your quote. This is what I was avoiding
by using multiplication instead of addition...

If just one argument
is a String, it converts the other to String and concatenates

The problem is that date1 is not an integer, it is an object. The
multiplication forced it to behave as an integer for the purpose of the
demonstration, however if + is used to force the transformation the
example risked failing because document.writeln('testing: '+date1) would
return a date string and not a date integer which is what I was discussing.

I didn't assume the end user would enter the example as entered, I
assumed that while exploring new code the user would expand on the
document.write string for debugging purposes which means using +date1
would yield unpredictable results if the user went from...

document.writeln(+date1); (shows integer value)
to
document.writeln('testing: '+date1); (shows string value, not what we
wanted).

By using multiplication in my example, I used javascript's order of
operation to my advantage since multiplication takes priority over
addition (and concatenation) which means that even if the user expands
on my original example, it will still work.

document.writeln('testing: '+date1*1); (still an integer).

Randy Webb correctly noted that

document.writeln('testing: '+(+date1)); (still an integer)

would resolve everything to the satisfaction of the great and holy faqs,
but as I said, I deliberately chose multiplication to contain any chance
of concatenation and to simplify the readability of the code for people
learning a new concept.

I think we've all agreed that next time I'll just use date1.getTime()
which will avoid this sort of totally pointless nitpicking.

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

To which I can only conclude you have no understanding of how the
internal julian system works and any further discussion is pointless
until you make an effort to learn it. Suffice it to say that given any
starting date and a julian integer I can calculate the exact destination
date both forward and reverse and any other element you would like from
number of days, weeks, years, even the number of leap years between the
two dates.

How do I know this is true? Because to javascript all date/time are
julian integers and from that it calculates the day of the week, the
week of the year, and tons of other nifty, useful information regardless
of leap years, and other uncertainties in our real world calendars. It
does all this millions of time every single day, every time someone does
ANYTHING with a date object.

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.

Did your FAQs and ECMA-232 teach you the following?

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

Unformed is right Try taking out the parenthesis around date1 and
seeing how superfluous they really are -- oh and don't go thinking
++date1 is going to make things right with the world either

So pardon me if I continue to march to my own drummer because books are
tools to serve us, if books are our masters then we are the tools

 

[Randy Webb]

pcx99 said the following on 11/29/2006 11:06 PM:

Randy Webb correctly noted that

document.writeln('testing: '+(+date1)); (still an integer)

would resolve everything to the satisfaction of the great and holy faqs,

It has nothing to do with your concept of "great and holy faqs" and my
comment had absolutely nothing to do with dates. My issue was with your
statement:

<quote>
+ is a concatenation element in javascript and may yield unpredictable
results.
</quote>

It had to do with that false statement. Date object or not.

 

[Matt Kruse]

Evidently you're not aware of the function of Julian dates in the
computer sciences.

Before you go correctly the good doctor about dates in this group, you
should probably demonstrate a deep and broad knowledge of the topic. Few
have learned and tried to document date calculation logic and calendar
systems as deeply as Mr. Stockton has.

Suffice it to say that given
any starting date and a julian integer I can calculate the exact
destination date both forward and reverse and any other element you
would like from number of days, weeks, years, even the number of leap
years between the two dates.

How many months are there between Jan 31 and Feb 1 (1 day)?
How about between Jan 1 and Feb 28 (59 days)?

 

[Randy Webb]

Matt Kruse said the following on 11/30/2006 12:52 AM:

Before you go correctly the good doctor about dates in this group, you
should probably demonstrate a deep and broad knowledge of the topic. Few
have learned and tried to document date calculation logic and calendar
systems as deeply as Mr. Stockton has.

Very very true and couldn't be said better.

How many months are there between Jan 31 and Feb 1 (1 day)?
How about between Jan 1 and Feb 28 (59 days)?

<humor>
<jumping up and down raising hand screaming "I know, I know">
Between being inclusive or exclusive?<giggle>
</humor>

 

[Dr J R Stockton]

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

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

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.


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

If you have a good reason you should explain it.

In my system,
document.write('example: ' + (+date1));
document.write('example: ' + +date1);
give identical results.
document.write('example: ' ++date1);

is of course different - but in all the programming languages I know
some whitespace cannot removed without consequences.

Some computationally-superfluous parentheses aid legibility, for some
readers. Authors should know that that pair is optional.

 

[Arnaud Diederen]

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

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.

Is the answer there ?
http://www.crockford.com/javascript/jsmin.html

Arnaud


--
Arnaud DIEDEREN
Software Developer
IONIC Software
Rue de Wallonie, 18 - 4460 Grace-Hollogne - Belgium
Tel: +32.4.3640364 - Fax: +32.4.2534737
mailto:[email protected]
http://www.ionicsoft.com

 

[pcx99]

It has nothing to do with your concept of "great and holy faqs" and my
comment had absolutely nothing to do with dates. My issue was with your
statement:

<quote>
+ is a concatenation element in javascript and may yield unpredictable
results.
</quote>

It had to do with that false statement. Date object or not.

It depends on your definition of unpredictable results. If you go from
a machine perspective then yes, you can -- obviously -- nitpick all you
want to try and justify your existence by being *THE AUTHORITY* on all
such matters. If you go from a human perspective then you can -- just
as obviously -- justify that concatenation elements do indeed have the
capacity to introduce unpredictable results from people who are learning
new language concepts and may not have a deep understanding of the order
of operation. Even the "good doctor" failed this one basic task, by
missing the importance of the parenthesis and would have fallen into the
exact trap I was trying to avoid by using multiplication instead of
addition.

So you say tomato and I say tamato, how you see the "problem" depends on
how you approach the problem. If you go soley from the textbooks and
faqs in the proper method of doing things then yes, +() is the most
efficient and standard. If you go strictly by real world usage given
the scope of the problem and the necessity to keep it simple and
relatively foolproof then obviously +() wasn't the best method to use
since the pitfalls snared even a self-proclaimed expert in the process.

I'm pretty sure I said I was done with this particular aspect of the
discussion but I've got a cold this morning so I'm cranky with time on
my hands, bad combo

 

[Richard Cornford]

pcx99 wrote:

... . If you go soley from the textbooks and
faqs in the proper method of doing things then yes, +() is the most
efficient and standard.

It is the fastest type-converting-to-number operator/method (by between
5 and 700%, depending on the environment and which alternative is used
for comparison).

If you go strictly by real world usage given
the scope of the problem and the necessity to keep it simple and
relatively foolproof then obviously +() wasn't the best method to use
... .

<snip>

The clearest type-conversion to number method is:-

Number(date1)

- as it is virtually self-documenting.

There no type-converting methods between the clearest and the fastest
that deserve consideration.

Richard.

 

[pcx99]

The clearest type-conversion to number method is:-

Number(date1)

- as it is virtually self-documenting.

There no type-converting methods between the clearest and the fastest
that deserve consideration.

Richard.

I've already conceded that date1.getTime() would have been the proper
choice to use instead of *1. Number would be the second best choice
and I am ashamed to admit that I never considered it either in the
original answer to the problem nor in the follow-up.

 

[Matt Kruse]

It's not a hard question, until a full month has actually passed the
answer is zero.

What is a "full month"? A month does not specify an amount of time, but a
relative period.

In this case the answer to the first question is
zero months 1 day and x/mins/secs hours

Days and hours are irrelevant, I just asked about months.

Your answer differs with that of my database:

1> SELECT DATEDIFF(mm,'January 31, 2006','February 1, 2006')
2> go
-----------
1

In the second case the
answer is 1 month 28 days and x hours/mins/secs.

The month has ticked from Jan to Feb in each example - why is there a
difference in the number of months between the two?

If you would like
the answers can be resolved to fractions of months which would make
the first answer non-zero (but still not one).

How would you resolve it to a fraction of a month, when you don't really
know how long a "month" is?

IMO, the logical way to compute a datediff for period month is to see how
many month changes happen between two dates. So the number of months between
Jan 31 and Feb 1 is 1, because one month change has happened.

Calculating number of months difference for an arbitrary time period (say,
31 days) is impossible without knowing the actual start date.

 

[Matt Kruse]

A decent question. You can average the months... ((daysinyear)/12),
this is good for fractional answers (4.25 months).

365/12 = 30.41 days.
So Jan 31 - Mar 1 isn't even 1 month?

This is one way to look at it, however strictly speaking, a month's
period of time has not passed.

A "month" is not a period of time. So there is no way to determine if it has
passed.

This is unacceptable for accounting
purposes and countdown timers which would be in danger of rendering an
incorrect number of months in the display. Go ask your payroll
manager to pay you based on datediff and you'll be laughed out of the
office

I'm not sure how payroll matters for monthly calculations.

The only real answer to the question of "How many months have passed between
two dates?" is "That depends on how you define it."

In the past, I've used a formula like this, which I think makes sense:

For two dates D1 and D2 (D2>D1), the number of months difference is
12*(Y2-Y1)+(M2-M1)-((D2-D1<0)?1:0)

So, examples:

Jan 31, 2005 : Y=2005, M=1, D=31
Mar 1, 2005 : Y=2005, M=3, D=1

12*(2005-2005)+(3-1)-((1-31<0)?1:0) = 0 + 2 - 1 = 1

Nov 20, 2005 : Y=2005, M=11, D=20
Feb 12, 2006 : Y=2006, M= 2, D=12

12*(2006-2005)+(2-11)-((12-20<0)?1:0) = 12 + -9 - 1 = 2

Nov 20, 2005 : Y=2005, M=11, D=20
Feb 21, 2006 : Y=2006, M= 2, D=21

12*(2006-2005)+(2-11)-((21-20<0)?1:0) = 12 + -9 - 0 = 3

I think this matches well with what people mean in conversation when they
ask if a month has passed, for example. If today is the 30th, and you say
"it's been exactly 1 month since X" you would expect X to have been on the
30th of the last month. Except if today is March 30th, in which "exactly
last month" is quite ambiguous

 

[pcx99]

Is the answer there ?
http://www.crockford.com/javascript/jsmin.html

Arnaud

No, though I can see why you would.

In the example we are discussing date1 is a date object. Worse, it's a
smart object. The value it returns depends on how it is used in javascript.

If you say writeln(date1) it's going to return a date string "January 1
2006" or something along that line. If you say writeln(+date1) then
it's going to return an integer value that the date object can convert
back into a string date. This integer value is a Julian date, it's the
number of milliseconds since 1/1/1970 and the date the object is
holding. (the date and integers below are pseudo, they are not exact
representations).

So here are a few examples:

date1 = string ( January 1 2006 )
date1*1= integer ( 1928392932 )
+date1 = integer ( 1928392932 )
"testing "+date1 = string+date string (testing January 1 2006)
"testing "+date1*1= string+integer (testing 1928392932)
"testing "+(+date1) = string+integer (testing 1928392932)

The parenthesis tell javascript to immediately do the operation between
the parenthesis first, before anything else is done with the expression.
So in this case they are not decorative or superfluous, they're there
to ensure that date1 is displayed as an integer and not a string. No
parenthesis is required with multiplication because multiplication is
always done before addition/subtraction and concatenation.

 

[pcx99]

The only real answer to the question of "How many months have passed between
two dates?" is "That depends on how you define it."

I think we can both agree to this. If you look at the thread from the
start and realize that we are now arguing about the methodology of
finding the number of months between two dates instead of whether it is
even possible as was originally asserted then I stand proven correct.
There may be different ways to go about it but given a starting date and
a julian number you can indeed calculate whatever element you wish
between the two dates including months (which was not part of my
original assertation but which I'm happy to embrace none-the-less)

As an aside it's pretty much a crime to snip your rather beautiful code
to average the months between two dates, I found it enlightening and
have clipped it into my toolbox because I do think there will be points
in the future where that method of date calculation will prove useful,
not in all circumstances of course but I can certainly see where if I
don't need exact matches to real world calendars that it's certainly
better than date averaging!

Thanks for sharing it. I didn't include it here for discussion because
we've wandered outside the scope of the debate into an area which
basically acknowledges that you can indeed get exact answers from
javascript's date object once you define the approach you are going to
use to extract said information.

 

[Matt Kruse]

In the example we are discussing date1 is a date object. Worse,
it's a smart object. The value it returns depends on how it is used
in javascript.

No it doesn't.

If you say writeln(date1) it's going to return a date string "January
1 2006" or something along that line.

Actually, inside of writeln it is calling toString, which the Date object
defines to return the text string.

If you say writeln(+date1) then it's going to return an integer value that
the date object can convert
back into a string date.

The unary + operator internally calls ToNumber, which internally calls
ToPrimitive with a hint of Number, which internally calls valueOf, which the
Date object defines as returning a number matching getTime().

Context doesn't matter (like it does, for example, in Perl). The internal
conversions of the Date object are what matters.

 

[Matt Kruse]

Actually, inside of writeln it is calling toString, which the Date
object defines to return the text string.
The unary + operator internally calls ToNumber, which internally calls
ToPrimitive with a hint of Number, which internally calls valueOf,
which the Date object defines as returning a number matching
getTime().

Oops, forgot to post the proof that I whipped up:

var d = new Date();
alert(d);
d.toString = function() { return "My date!"; }
alert(d);
alert(+d);
d.valueOf = function() { return 42; }
alert(+d);

 

[Randy Webb]

pcx99 said the following on 11/30/2006 12:49 PM:

No, though I can see why you would.

Actually, my reason for wrapping it is very much related to that page.

Use any string that can be converted to a number, remove the whitespace
(which is allowed in most JS) and execute it:

myString1 = "123";
myString2 = "456";

alert((+myString1) + (+myString2));
//alerts 579 as expected
alert(+myString1++myString2);
//JS error

The example is simplified but shows the error that can be caused by the
omission of the enclosing parentheses.

 

[Randy Webb]

Dr J R Stockton said the following on 11/30/2006 6:07 AM:

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


If you have a good reason you should explain it.
In my system,
document.write('example: ' + (+date1));
document.write('example: ' + +date1);
give identical results.
document.write('example: ' ++date1);

is of course different - but in all the programming languages I know
some whitespace cannot removed without consequences.

Wrap it in parentheses and it can be removed without consequence.

Some computationally-superfluous parentheses aid legibility, for some
readers. Authors should know that that pair is optional.

They are not "computationally-superfluous" nor are they plain
superfluous they are there for a very good reason.

Read my entire answer and the reason becomes obvious.

 

[Dr J R Stockton]

In comp.lang.javascript message

Still arbitrarily set. It could have been 01/01/1969 or 10/25/1955,
from a coding perspective there's no difference between the two.


Evidently you're not aware of the function of Julian dates in the
computer sciences. COBOL uses 01/01/1601. NASA uses 5/24/1968.
The PICK OS used 01/01/1965. Astronomers have their own julian system
and there are various other niche systems. These are all Julian date
systems which represents the passage of time with a simple integer.
There is no single Julian date, there is an original Julian calendar
and there are a plethora of additional Julian systems with different
starting dates. The selection of 1/1/1970 was an arbitrary decision by
the developers of the language, 1/2/1970 would have worked just as well
as far as javascript is concerned.

Note that, as a date string, "1/2/1970" is unsatisfactory. Generally it
means 1 Feb 1970, but there are odd places that take it as Jan 2 1970.

There is one internationally defined and accepted Julian date system; it
is that often attributed to Scaliger but actually introduced by the
astronomer John Herschel in 1849. Its zero is Julian BC 4713-01-01
12:00:00 GMT.

COBOL, NASA, etc. use their own daycount systems. NASA does not use
Julian Date; it uses Truncated Julian Date, which is Modified Julian
Date either modulo 10000 or minus 40000. The origin of Pick is
1968-01-01, not 1965-01-01, I gather. Some of them may incorrectly use
the term Julian Date, but that is mere slovenliness.

COBOL actually uses 1600-12-31 as Day Zero. Likewise Pick. But those
who count from 1970-01-01 use that as Day Zero.

Not. There's no error with the code.

Agreed; I did not say that there was. I said that you made an incorrect
statement. You wrote :-

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

Those are actually GMT 2006 Nov 22 03:00:00 and 04:00:00; the figures
you give will only be obtained by those who are chronologically retarded
by six hours - Mexico, etc.

The time zone is simply not a factor in the problem or solution.


This is the relevant part from your quote. This is what I was avoiding
by using multiplication instead of addition...

The problem is that date1 is not an integer, it is an object. The
multiplication forced it to behave as an integer for the purpose of the
demonstration, however if + is used to force the transformation the
example risked failing because document.writeln('testing: '+date1)
would return a date string and not a date integer which is what I was
discussing.

It is only unary + that is always in effect a to-Number operator. A
binary + often concatenates, but not always - 3+true gives 4.

I didn't assume the end user would enter the example as entered, I
assumed that while exploring new code the user would expand on the
document.write string for debugging purposes which means using +date1
would yield unpredictable results if the user went from...

document.writeln(+date1); (shows integer value)
to
document.writeln('testing: '+date1); (shows string value, not what we
wanted).

The result is perfectly predictable. The naive user should have
considered what the purpose + may have been, and preserved that effect
by using another + to concatenate.

By using multiplication in my example, I used javascript's order of
operation to my advantage since multiplication takes priority over
addition (and concatenation) which means that even if the user expands
on my original example, it will still work.

document.writeln('testing: '+date1*1); (still an integer).

Randy Webb correctly noted that

document.writeln('testing: '+(+date1)); (still an integer)

I don't recall that he did, though he would have been correct if he had
done so. He actually wrote

document.writeln('testing: ' + (+date1)); (still an integer)

would resolve everything to the satisfaction of the great and holy
faqs, but as I said, I deliberately chose multiplication to contain any
chance of concatenation and to simplify the readability of the code for
people learning a new concept.

I think we've all agreed that next time I'll just use date1.getTime()
which will avoid this sort of totally pointless nitpicking.

Date1.valueOf() is better.

To which I can only conclude you have no understanding of how the
internal julian system works and any further discussion is pointless
until you make an effort to learn it. Suffice it to say that given any
starting date and a julian integer I can calculate the exact
destination date both forward and reverse and any other element you
would like from number of days, weeks, years, even the number of leap
years between the two dates.

I know how the Javascript system works, and I know that Julian Dates,
either in the proper meaning or the IBM meaning, are not involved.

How do I know this is true? Because to javascript all date/time are
julian integers and from that it calculates the day of the week, the
week of the year,

ECMA Javascript, unaided by extra code, has NO capability for
week-of-the-year. It is possible that some implementations may have
added it. VBScript has it; but the default ignores the International
Standard and the particular case that seems to give ISO numbers gets a
few days wrong.

and tons of other nifty, useful information regardless of leap years,
and other uncertainties in our real world calendars.

There are no uncertainties in the Gregorian Calendar, apart from how
long it will be used for. There are uncertainties in some
middle-Eastern calendars, but Javascript has nothing for those built-in.

It does all this millions of time every single day, every time
someone does ANYTHING with a date object.

Not strictly true. There are things which one can do with a Date Object
which involve no knowledge of the Calendar or Clock at all. At least
one of them is actually useful - see the FAQ.

Unformed is right Try taking out the parenthesis around date1 and
seeing how superfluous they really are

The inner parentheses are superfluous. But the two plus signs must not
be consecutive characters.

 

[Dr J R Stockton]

Calculating number of months difference for an arbitrary time period (say,
31 days) is impossible without knowing the actual start date.

Strictly, only impossible for Calendar Months (and disregarding Summer
Time). There's an accounting convention of 30-day months - seek DAYS360
in Help of Excel, if available, and maybe elsewhere.

<URL:http://www.merlyn.demon.co.uk/moredate.htm#M30D> refers.


= = = = =

In the unlikely event of anyone using holidays.htm#AW with their own
data-set : Implementing the consequences of yesterday's decision of the
Scottish Parliament, I found a need to deal with a case not previously
encountered - Day Off in a different month. Assuming FTP works, the new
page will have been uploaded by about when you read this.

 

[Dr J R Stockton]

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

pcx99 said the following on 11/30/2006 12:49 PM:

Actually, my reason for wrapping it is very much related to that page.

Use any string that can be converted to a number, remove the whitespace
(which is allowed in most JS) and execute it:

myString1 = "123";
myString2 = "456";

alert((+myString1) + (+myString2));
//alerts 579 as expected
alert(+myString1++myString2);
//JS error

The example is simplified but shows the error that can be caused by the
omission of the enclosing parentheses.

It does not. It shows that omitting the enclosing parentheses AND ALSO
removing two spaces is wrong.

There are other cases where a space must not be removed :
do X=3;while(false)
case 99:
break Fred
return Ticket
new Date()

Removing one of the spaces as well as the parentheses changes the
statement from holding two + tokens to holding one ++ token.

Those parentheses may provide idiot-proofing; but a
correctly-implemented Javascript engine, while sometimes seeming
perverse, is not an idiot.