testing if date is in past

[Mike P]

How would I write some Javascript to test whether a date is in the past
or not? I need to only accept either the current date or future dates.

 

[Martin Honnen]

How would I write some Javascript to test whether a date is in the past
or not? I need to only accept either the current date or future dates.

Well
var now = new Date();
gives you the current date. Then construct a second date e.g.
var d1 = new Date(2009,0,1);
and compare them e.g.
if (d1 >= now)

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
cor-online.net>, Thu, 30 Oct 2008 18:44:43, Martin Honnen

Mike P wrote:

var now = new Date();
gives you the current date. Then construct a second date e.g.
var d1 = new Date(2009,0,1);
and compare them e.g.
if (d1 >= now)

Better IMHO to write d1 as new Date("2009/01/01") in general because
the second argument of new Date(y,m,d) does not match the month-
numbering used in the Outside World.

One needs to think about whether the present day should be considered as
in the past or not. One may want to use now.setHours(0,0,0,0) or
now.setHours(24,0,0,0) --- remembering that in the Azores there is one
day each year which does not start at 00:00:00 and another that has
00:00:00 twice - I think.

 

[Evertjan.]

Martin Honnen wrote on 30 okt 2008 in comp.lang.javascript:

Well
var now = new Date();
gives you the current date. Then construct a second date e.g.
var d1 = new Date(2009,0,1);
and compare them e.g.
if (d1 >= now)

if now were 2009/jan/1 11:33
then (d1 >= now) would be false.

 

[Dr J R Stockton]

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

if now were 2009/jan/1 11:33
then (d1 >= now) would be false.

I find it quicker to put a unary + before each date Object than to try
to remember how relational operators work between date Objects; YMMV.

 

[Evertjan.]

Dr J R Stockton wrote on 31 okt 2008 in comp.lang.javascript:

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


I find it quicker to put a unary + before each date Object than to try
to remember how relational operators work between date Objects; YMMV.

True, but that would not help in the above case, John.

 

[Dr J R Stockton]

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

Dr J R Stockton wrote on 31 okt 2008 in comp.lang.javascript:


True, but that would not help in the above case, John.

No : my other article refers to that problem but does not say + is
necessary.

 

[Thomas 'PointedEars' Lahn]

Martin Honnen posted:

Better IMHO to write d1 as new Date("2009/01/01") in general because
the second argument of new Date(y,m,d) does not match the month-
numbering used in the Outside World.

It would be rather unwise to do that as when the first argument of the Date
constructor is a string value, it is specified in ECMAScript Ed. 3 Final,
section 15.9.3.2, that the value should be parsed "in exactly the same
manner as for the parse method (section 15.9.4.2); let V be the time value
for this date.".

However it is specified there that "The string may be interpreted as a local
time, a UTC time, or a time in some other time zone, depending on the
contents of the string."; in other words, it is _not_ specified there.
Therefore, using "YYYY/DD/MM" may or may not work in an implementation, and
for that matter that implementation would still be compliant with ECMAScript
Ed. 3.

In contrast, the numeric multi-argument variant is well-specified in section
15.9.3.1, and well-supported.

A wrapper method or developer's algorithm (subtract 1) can provide for the
syntactic sugar; however, for a developer it should not be unusual to
encounter zero-based indexes, so the Outside World argument must be
questioned here.


PointedEars

 

[Dr J R Stockton]

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

It would be rather unwise to do that as when the first argument of the Date
constructor is a string value, it is specified in ECMAScript Ed. 3 Final,
section 15.9.3.2, that the value should be parsed "in exactly the same
manner as for the parse method (section 15.9.4.2); let V be the time value
for this date.".

However it is specified there that "The string may be interpreted as a local
time, a UTC time, or a time in some other time zone, depending on the
contents of the string."; in other words, it is _not_ specified there.
Therefore, using "YYYY/DD/MM" may or may not work in an implementation, and
for that matter that implementation would still be compliant with ECMAScript
Ed. 3.

In contrast, the numeric multi-argument variant is well-specified in section
15.9.3.1, and well-supported.

A wrapper method or developer's algorithm (subtract 1) can provide for the
syntactic sugar; however, for a developer it should not be unusual to
encounter zero-based indexes, so the Outside World argument must be
questioned here.

You are a legalistic twit. I've tested versions of five major browsers
myself, and all accept that form. I've asked for counterexamples, and
none have ever been provided. By your reasoning, no string form would
be usable.

Granted, there are two known traps with new Date(String).

One cannot safely use DD/MM/YYYY or MM/DD/YYYY, since both forms are in
use in the Real World, and a browser might choose to prefer either.
YYYY/MM/DD is safe; one has to be really stupid to choose YYYY/DD/MM or
YYYYDDMM - AFAIK, that has only ever been done at the Federal level.

And one cannot safely use alphabetic offset indicators other than GMT &
UTC, since they are not otherwise standardised. NASA do not show signs
of knowing that, though they have been told.

Neither trap applies in this case.

As for your silly "zero-based" argument - the Gregorian Month in the
real world is always numerically represented by 1 to 12, as per ISO
8601. Therefore, it is unreasonable to expect people editing code
always to remember to use numbers 0 to 11, whereas if they are editing a
YYYY/MM/DD string there will be no problem.

You should not be arguing against supporting an important and useful ISO
standard.

As far as I can see, de.c.l.j also find you to be offensively socially
abnormal (which is a relief, in a way). You should try to grow up and
act as a normal human being. Psycho-medical services can do wonders
these days, they say.

 

[Dr J R Stockton]

In comp.lang.javascript message <UdCdnXHl4ZFN1JPUnZ2dnUVZ_q7inZ2d@supern

[..] whereas if they are editing a YYYY/MM/DD string there will be
no problem.

You should not be arguing against supporting an important and useful
ISO standard.

ISO standard is "YYYY-MM-DD".

In software, date formats that contain slashes always make me run for
cover. And yes, I have actually seen people use the form YYYY/DD/MM.

One supports the Standard by coming as near as is practical to using it.
Had I meant following it, which implies full compliance, I would have
used that word. But, as no known (by me) browser will accept new
Date("2008-11-03") , it is new Date("2008/11/03") which should be
used to set that date, LCT, in code.

When programming, one can use
new Date(FORM.control.value.replace(/-/g. "/"))
to permit any mix of - & / and .replace(/(\d\d)(\d\d)$/, "/$1/$2")
to permit YYYYMMDD.

 

[Michael Wojcik]

ISO standard is "YYYY-MM-DD".

I suspect the good doctor is aware of that, as is anyone who's read
his Date and Time Miscellany.

And ISO 8601:2004(E) specifies a number of formats, not just the one
you cite.

 

[Thomas 'PointedEars' Lahn]

Conrad Lender posted:

[..] whereas if they are editing a YYYY/MM/DD string there will be
no problem.

You should not be arguing against supporting an important and useful
ISO standard.

ISO standard is "YYYY-MM-DD".

In software, date formats that contain slashes always make me run for
cover. And yes, I have actually seen people use the form YYYY/DD/MM.

One supports the Standard by coming as near as is practical to using it.
Had I meant following it, which implies full compliance, I would have
used that word. But, as no known (by me) browser will accept new
Date("2008-11-03") , it is new Date("2008/11/03") which should be
used to set that date, LCT, in code.

You must be kidding. You can *meet* the standard already by using the
numeric variant, yet you recommend that one should run the risk of getting
a wrong time value by assuming that unspecified behavior was interoperable
in the attempt to come *as close as possible* to another that is entirely
irrelevant here.

There's a word for such an argumentation, and I guess you know it.

When programming, one can use
new Date(FORM.control.value.replace(/-/g. "/"))
to permit any mix of - & / and .replace(/(\d\d)(\d\d)$/, "/$1/$2")
to permit YYYYMMDD.

It's a good possibility, but insufficient to back up your argument. In
fact, accessibility guidelines call for user interfaces to provide separate
controls for date input.


PointedEars