Multiple Auto Expire Script

[David J Trower]

I am not that familiar with JavaScript, just enough that I can piece
together a script when looking at some examples that are similar to
what I want. However, I have reached a snag. I am working on a
script that I can have a list of multiple upcoming events, and the
JavaScript go through them and when it finds the one that should
currently be shown, displays it. I have the script working if I have
only one event in the code for it to parse, but I am wanting to avoid
having to edit the code on a weekly basis. Below is my code as it
currently stands. Any help would be greatly appreciated.

// var expireEvents = "06-24-2010-13-00-07-01-2010-12-59-Upcoming
Program-Greg Evans, 2010-2011 Northwest Waco Rotary President-July
1, 2010";
// var expireEvents = "07-01-2010-13-00-07-08-2010-12-59-Upcoming
Program-Kurt Slaughter, Texas Parks and Wildlife Game Warden-July 8,
2010";
// var expireEvents = "07-08-2010-13-00-07-15-2010-12-59-Upcoming
Program-Mike Cain, Oncor Area Manager-July 15, 2010";
var expireEvents = "07-15-2010-13-00-07-22-2010-12-59-Upcoming Program-
TBA-July 22, 2010";
// var expireEvents = "07-22-2010-13-00-07-29-2010-12-59-Upcoming
Program-Jason Jennings, Hillcrest COO-July 29, 2010";
// var expireEvents = "07-29-2010-13-00-08-05-2010-12-59-Upcoming
Program-Wes Allison, HOT Fair-August 5, 2010";
// var expireEvents = "08-05-2010-13-00-08-12-2010-12-59-Upcoming
Program-John Morris, 2010 Baylor Football Preview-August 12, 2010";
// var expireEvents = "08-12-2010-13-00-08-15-2010-00-00-Upcoming
Event-Beach Party with <em>The Morticians</em>-August 14, 2010";
// var expireEvents = "07-20-2010-15-30-07-25-2010-22-29-Upcoming
Program-Guest Speaker, XYZ Company-July 20, 2010";

var expireEvents = expireEvents.split('-');
var goLiveMonth;
var goLiveDay;
var goLiveYear;
var goLiveHour;
var goLiveMinute;
var expireMonth;
var expireDay;
var expireYear;
var expireHour;
var expireMinute;
var expireDST;
var exeventHeader;
var exeventSpeaker;
var exeventDate;
var goLiveDate;
var expireDate;
var mycontent;

goLiveMonth = expireEvents[0];
goLiveDay = expireEvents[1];
goLiveYear = expireEvents[2];
goLiveHour = expireEvents[3];
goLiveMinute = expireEvents[4];
expireMonth = expireEvents[5];
expireDay = expireEvents[6];
expireYear = expireEvents[7];
expireHour = expireEvents[8];
expireMinute = expireEvents[9];
exeventHeader = expireEvents[10];
exeventSpeaker = expireEvents[11];
exeventDate = expireEvents[12];

var goLiveDate = goLiveYear + goLiveMonth + goLiveDay + ' ' +
goLiveHour + ':' + goLiveMinute;
var expireDate = expireYear + expireMonth + expireDay + ' ' +
expireHour + ':' + expireMinute;
var mycontent = '<div id="labelzone"><br /><h3>' + exeventHeader + '</
h3><p>' + exeventSpeaker + '<br />' + exeventDate + '</p></div><!--
#labelzone-->';

var nowDate = new Date();
var day = nowDate.getDate();
var month = nowDate.getMonth();
var correctedMonth = month + 1; //month - JavaScript starts at "0"
for January, so we add "1"

if (correctedMonth < 10) { /* if less than "10", put a "0" in front
of the number. */
correctedMonth = "0" + correctedMonth;
}

if (day < 10) { /* if less than "10", put a "0" in front of the
number. */
day = "0" + day;
}

var year = nowDate.getYear(); /* Get the year. Firefox and Netscape
might use century bit, and two-digit year. */
if (year < 1900) {
year = year + 1900; /*This is to make sure Netscape AND FireFox
doesn't show the year as "107" for "2007." */
}

var hour = nowDate.getHours(); /* Get the hour. */
if (hour < 10) {
hour = "0" + hour;
}

var minute = nowDate.getMinutes(); /* Get the minute. */
if (minute < 10) {
minute = "0" + minute;
}

var GMTdate = year + "" + correctedMonth + "" + day + " " + hour + ":"
+ minute; //corrected month GMT date.

if ((GMTdate <= expireDate) && (GMTdate >= goLiveDate)) {
document.write(mycontent)
}

 

[Mike Duffy]

:

.... Below is my code as it currently stands.
Any help would be greatly appreciated.

Why not use the standard Javascript date format for your date strings?
Then you could just use standard date parsing. The first event would
look something like:

expireEvents = { "Jun 24 2010 13:00", "Ju1 01 2010 12:59", "Greg
Evans", "Northwest Waco Rotary" };

If you use this format for the dates, then you can get rid of most of
the other code and replace it with

GMTdate = new Date();

expireDate = new Date (Date.parse(expireEvents[1]));
goliveDate = new Date (Date.parse(expireEvents[0]));

if ((GMTdate >= goLiveDate) && (GMTdate < expireDate))
{
document.write(expireEvents[2] + expireEvents[3] + "htm fmts etc." )
};

 

[Thomas 'PointedEars' Lahn]

[...] I am working on a script that I can have a list of multiple
upcoming events, and the JavaScript go through them and when it finds the
one that should currently be shown, displays it. I have the script
working if I have only one event in the code for it to parse, but I am
wanting to avoid having to edit the code on a weekly basis. [...]

// var expireEvents = "06-24-2010-13-00-07-01-2010-12-59-Upcoming
Program-Greg Evans, 2010-2011 Northwest Waco Rotary President-July
1, 2010";
[...]
// var expireEvents = "07-20-2010-15-30-07-25-2010-22-29-Upcoming
Program-Guest Speaker, XYZ Company-July 20, 2010";

var expireEvents = expireEvents.split('-');
var goLiveMonth;
[…]
var exeventDate;
var goLiveDate;
var expireDate;
var mycontent;

goLiveMonth = expireEvents[0];
[…]
exeventDate = expireEvents[12];

That is a terrible waste, and easily leads to inconsistent code. Consider
instead

var goLiveMonth = expireEvents[0];
…
var exeventDate = expireEvents[12];

or to save even more typing and storage:

var
goLiveMonth = expireEvents[0],
…
exeventDate = expireEvents[12];

Even better, consider using an object being initialized in a loop:

var
aParts = ["goLiveMonth", "goLiveDay", …],
oEvent = {};

for (var i = aParts.length; i--
{
oEvent[parts] = expireEvents;
}

or, if you find that more intuitive (although due to the function calls it
is probably less efficient),

aParts.forEach(function (e) {
oEvent[e] = expireEvents;
});

(the latter being natively available only in newer implementations.)

If you are talking JavaScript 1.7 and later, you can even do

var [goLiveMonth, goLiveDay, …] = expireEvents.split('-');

but, as I indicated before, I recommend to avoid declaring too many
variables.

var year = nowDate.getYear(); /* Get the year. Firefox and Netscape
might use century bit, and two-digit year. */
if (year < 1900) {
year = year + 1900; /*This is to make sure Netscape AND FireFox
doesn't show the year as "107" for "2007." */
}

Use nowDate.getFullYear() instead of this crude, error-prone workaround.

BTW, Netscape development and support has been ended by its vendor AOL two
years ago: <http://browser.netscape.com/>

As for your question, though, simply do not use only string values:

var expireEvents = [
{
goLive: new Date(2010, 5, 24, 13),
expire: new Date(2010, 6, 1, 12, 59),
header: "Upcoming Program",
speaker: "Greg Evans, 2010-2011 Northwest Waco Rotary President",
date: new Date(2010, 6, 1)
},
…
];

(If you find the `Date' constructor confusing, write a wrapper function that
you call instead. Probably the `goLive' and `expire' values do not need to
be hard-coded in the first place. You could have a constructor that
computes those values depending on the date passed to it.)

`expireEvents' then stores a reference to an Array instance that has
references to Object instances as its elements that you can iterate over.

You really want to do this server-side (at least partially), though,
regardless of the programming language you would use then.

Please read the FAQ of this newsgroup before asking further questions:
<http://jibbering.com/faq/>


HTH

PointedEars

 

[Thomas 'PointedEars' Lahn]

[...] I am working on a script that I can have a list of multiple
upcoming events, and the JavaScript go through them and when it finds the
one that should currently be shown, displays it. I have the script
working if I have only one event in the code for it to parse, but I am
wanting to avoid having to edit the code on a weekly basis. [...]

// var expireEvents = "06-24-2010-13-00-07-01-2010-12-59-Upcoming
Program-Greg Evans, 2010-2011 Northwest Waco Rotary President-July
1, 2010";
[...]
// var expireEvents = "07-20-2010-15-30-07-25-2010-22-29-Upcoming
Program-Guest Speaker, XYZ Company-July 20, 2010";

var expireEvents = expireEvents.split('-');
var goLiveMonth;
[…]
var exeventDate;
var goLiveDate;
var expireDate;
var mycontent;

goLiveMonth = expireEvents[0];
[…]
exeventDate = expireEvents[12];

That is a terrible waste, and easily leads to inconsistent code. Consider
instead

var goLiveMonth = expireEvents[0];
…
var exeventDate = expireEvents[12];

or to save even more typing and storage:

var
goLiveMonth = expireEvents[0],
…
exeventDate = expireEvents[12];

Even better, consider using an object being initialized in a loop:

var
aParts = ["goLiveMonth", "goLiveDay", …],
oEvent = {};

for (var i = aParts.length; i--
{
oEvent[aParts] = expireEvents;
}

or, if you find that more intuitive (although due to the function calls it
is probably less efficient),

aParts.forEach(function (e, i) {
oEvent[e] = expireEvents;
});

(the latter being natively available only in newer implementations.)

If you are talking JavaScript 1.7 and later, you can even do

var [goLiveMonth, goLiveDay, …] = expireEvents.split('-');

but, as I indicated before, I recommend to avoid declaring too many
variables.

var year = nowDate.getYear(); /* Get the year. Firefox and Netscape
might use century bit, and two-digit year. */
if (year < 1900) {
year = year + 1900; /*This is to make sure Netscape AND FireFox
doesn't show the year as "107" for "2007." */
}

Use nowDate.getFullYear() instead of this crude, error-prone workaround.

BTW, Netscape development and support has been ended by its vendor AOL two
years ago: <http://browser.netscape.com/>

As for your question, though, simply do not use only string values:

var expireEvents = [
{
goLive: new Date(2010, 5, 24, 13),
expire: new Date(2010, 6, 1, 12, 59),
header: "Upcoming Program",
speaker: "Greg Evans, 2010-2011 Northwest Waco Rotary President",
date: new Date(2010, 6, 1)
},
…
];

(If you find the `Date' constructor confusing, write a wrapper function that
you call instead. Probably the `goLive' and `expire' values do not need to
be hard-coded in the first place. You could have a constructor that
computes those values depending on the date passed to it.)

`expireEvents' then stores a reference to an Array instance that has
references to Object instances as its elements that you can iterate over.

You really want to do this server-side (at least partially), though,
regardless of the programming language you would use then.

Please read the FAQ of this newsgroup before asking further questions:
<http://jibbering.com/faq/>


HTH

PointedEars

 

[Thomas 'PointedEars' Lahn]

Why not use the standard Javascript date format for your date strings?
The first event would look something like:

expireEvents = { "Jun 24 2010 13:00", "Ju1 01 2010 12:59", "Greg
Evans", "Northwest Waco Rotary" };

You don't know what you are talking about (which is unsurprising for a
person who anti-socially blocks e-mail communication on Usenet, though).

There is no "Javascript" to begin with, much less a "standard Javascript".
As for standards, ECMAScript Edition 5:

| 15.9.1.15 Date Time String Format
|
| ECMAScript defines a string interchange format for date-times based upon a
| simplification of the ISO 8601 Extended Format. The format is as follows:
| YYYY-MM-DDTHH:mm:ss.sssZ
| [...]
|
| 15.9.4.2 Date.parse (string)
|
| The parse function applies the ToString operator to its argument and
| interprets the resulting String as a date and time; it returns a Number,
| the UTC time value corresponding to the date and time. 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. 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. [...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And ECMAScript Edition 3 Final:

| 15.9.4.2 Date.parse (string)
|
| The parse function applies the ToString operator to its argument and
| interprets the resulting string as a date; it returns a number, the UTC
| time value corresponding to the date. 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.
|
| If x is any Date object whose milliseconds amount is zero within a
| particular implementation of ECMAScript, then all of the following
| expressions should produce the same numeric value in that implementation,
| if all the properties referenced have their initial values:
|
| x.valueOf()
| Date.parse(x.toString())
| Date.parse(x.toUTCString())
|
| However, the expression Date.parse(x.toLocaleString()) is not required to
| produce the same number value as the preceding three expressions and, in
| general, the value produced by Date.parse is implementation-dependent when
| given any string value that could not be produced in that implementation
| by the toString or toUTCString method.

Guess how many conforming implementations of ES 3 (2000 CE) and how many of
ES 5 (2010 CE) are out there. Guess again.


PointedEars

 

[David Mark]

On Jul 22, 4:54 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:

[...]

      date:    new Date(2010, 6, 1)

Careful on this one. In rare cases, in some time zones, this can
underflow to the previous day (and month in this example). Has to do
with DST, IIRC. Of course, that won't matter unless you are going to
display it, convert it to a string, retrieve the day, etc. In other
words, if it will only be used to calculate time spans, it's fine.

I have code that fixes this and will post if there is any interest. I
once attempted to use it to fix a bug in the Dojo calendar; but, as
usual they went into "show me where it fails" mode. They understood
the underlying problem, but could not grasp why they should not change
the Date object that is passed to the widget's constructor and exposed
as a property (or retrieved by a method). It seemed like a simple
enough concept to me: GIGO. Don't screw with it until you have to
display it (and then screw with a copy, not the original). IIRC,
their meddlesome solution was a line or two shorter and "worked" as
they saw it.

 

[Thomas 'PointedEars' Lahn]

Careful on this one. In rare cases, in some time zones, this can
underflow to the previous day (and month in this example). Has to do
with DST, IIRC.

You must be mistaken. According to
<http://www.worldtimezone.org/daylight.html>, there is not going to be any
DST switch anywhere on this planet near *July* 1st of the Gregorian
calendar. Indeed, it does not make any sense to switch to or from
*Daylight* Saving Time/*Summer* Time near the mid (solstice) of summer
(Northern Hemisphere) or winter (Southern Hemisphere) rather than near the
beginning or end of either one (equinox).

Also, assuming that there would be such a switch date as you suggest, a date
underflow would be non-standard behavior, an implementation (or version of
an implementation) that is FUBAR and not worth considering. For example,
the next switch from Central European Summer Time (CEST) back to CET is
going to be at 2010-10-31 03:00:00.000 GMT+02:00 CEST here; but (new
Date(2010, 9, 31)).getDate() yields 31 in all 6 major implementations (do I
need to name them?) here, of course.

So, since *you* are making that claim, I daresay unto you "Show me where
(and when) it fails."

In other words, if it will only be used to calculate time spans, it's
fine.

Wouldn't it be the other way around?


PointedEars

 

[John G Harris]

On Jul 22, 4:54 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:

[...]

      date:    new Date(2010, 6, 1)

Careful on this one. In rare cases, in some time zones, this can
underflow to the previous day (and month in this example). Has to do
with DST, IIRC. Of course, that won't matter unless you are going to
display it, convert it to a string, retrieve the day, etc. In other
words, if it will only be used to calculate time spans, it's fine.

I have code that fixes this

<snip>

new Date(2010, 6, 1, 12, 0, 0)
fixes it.

John

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
[...]

date: new Date(2010, 6, 1)

Careful on this one. In rare cases, in some time zones, this can
underflow to the previous day (and month in this example). Has to do
with DST, IIRC. Of course, that won't matter unless you are going to
display it, convert it to a string, retrieve the day, etc. In other
words, if it will only be used to calculate time spans, it's fine.

I have code that fixes this

<snip>

new Date(2010, 6, 1, 12, 0, 0)
fixes it.

No, if there would be a *general* problem with the call above (and there is
not, possibly borken *tzdata* implementations in the *OS* aside), then your
call would not be a fix; it could, at most, slightly reduce the likelihood
that a problem could occur.


PointedEars

 

[David Mark]

>On Jul 22, 4:54 am, Thomas 'PointedEars' Lahn"]
wrote:

[...]

      date:    new Date(2010, 6, 1)

Careful on this one.  In rare cases, in some time zones, this can
underflow to the previous day (and month in this example).  Has to do
with DST, IIRC.  Of course, that won't matter unless you are going to
display it, convert it to a string, retrieve the day, etc.  In other
words, if it will only be used to calculate time spans, it's fine.

I have code that fixes this

  <snip>

  new Date(2010, 6, 1,  12, 0, 0)
fixes it.
[/QUOTE]

I don't recall that it did and would be surprised to find out that is
the case (as I imagine that I would have tried it). I'll try to dig
up a date and TZ that demonstrates the issue.

 

[David Mark]

You must be mistaken.

Hardly, I've seen the bug in action.

According to
<http://www.worldtimezone.org/daylight.html>, there is not going to be any
DST switch anywhere on this planet near *July* 1st of the Gregorian
calendar.

I didn't mean to imply that there was a problem with that specific
date. Quite the contrary, the problem dates are few and far between,
so it would have been extraordinarily bad luck for you to have hit one
in your example.

Indeed, it does not make any sense to switch to or from
*Daylight* Saving Time/*Summer* Time near the mid (solstice) of summer
(Northern Hemisphere) or winter (Southern Hemisphere) rather than near the
beginning or end of either one (equinox).

That's irrelevant, but sorry for any confusion.

Also, assuming that there would be such a switch date as you suggest, a date  
underflow would be non-standard behavior, an implementation (or version of
an implementation) that is FUBAR and not worth considering.

The problem I saw existed in at least one major desktop browser
(latest version at the time) on Windows. We did discuss this problem
here as well (back around October of last year).

For example,
the next switch from Central European Summer Time (CEST) back to CET is
going to be at 2010-10-31 03:00:00.000 GMT+02:00 CEST here; but (new
Date(2010, 9, 31)).getDate() yields 31 in all 6 major implementations (doI
need to name them?) here, of course.

You have to change your time zone settings to see the problem. I
don't recall which time zones were affected.

So, since *you* are making that claim, I daresay unto you "Show me where
(and when) it fails."

It's been posted here. Perhaps Google for comp.lang.javascript + date
+ underflow + Stockton + Mark, etc.

Wouldn't it be the other way around?

No. It's the serialization and presentation that get busted.
Internally, it's just a number. Fudging the number (e.g. the Dojo
example) is unnecessary and will likely lead to incorrect
calculations.

 

[Mike Duffy]

You don't know what you are talking about (which is unsurprising
for a person who anti-socially blocks e-mail communication on
Usenet, though).

There is no "Javascript" to begin with, much less a "standard
Javascript". As for standards, ECMAScript Edition 5:
PointedEars

As usual, you are technically correct. I should have said something
like:

Most browsers provide scripting which support the following (or
similar) functions which will allow you to get rid of most of the
convoluted error-prone code in your example.


But I do take take exception to your assertion that my ignorance of
javascript (as referred to by us yokels) has a correlation to being
anti-social. The blocking of my email address in my newsreader is
part of my general strategy to prevent spam. I have been using the
same email address for 3 years now, and during that time have
received only 2 spam messages. What is your score in that regard?

In fact, I have recently re-established the signature block at the
end of my postings with a link to my personal web-site. On the main
page there is a link to a page with a form people can use to send me
email. Feel free to use it yourself.

 

[David Mark]

[...]

No.  It's the serialization and presentation that get busted.
Internally, it's just a number.  Fudging the number (e.g. the Dojo
example) is unnecessary and will likely lead to incorrect
calculations.

I should add that it depends on the type of calculations that will be
done. Anything dependent on retrieving the day, month or year will
certainly require the underflow fix. In contrast if you are dealing
with the "raw" numbers (e.g. finding the difference, adding an offset,
etc.), you shouldn't meddle. After giving this some thought, in the
case where times are not involved (which is the only case where the
bug is present), the latter type would be (by far) more common, so
Thomas makes a good point.

 

[David Mark]

[...]

No.  It's the serialization and presentation that get busted.
Internally, it's just a number.  Fudging the number (e.g. the Dojo
example) is unnecessary and will likely lead to incorrect
calculations.

I should add that it depends on the type of calculations that will be
done.  Anything dependent on retrieving the day, month or year will
certainly require the underflow fix.  In contrast if you are dealing
with the "raw" numbers (e.g. finding the difference, adding an offset,
etc.), you shouldn't meddle.  After giving this some thought, in the
case where times are not involved (which is the only case where the
bug is present), the latter type would be (by far) more common, so
Thomas makes a good point.

And I should also re-emphasize that if an object (e.g. a widget)
stores a Date object that has been passed to it and allows for that
Date object to be retrieved (e.g. with a method call), that Date
object *must* remain inviolate. Any fiddling should be done with a
copy, so as not to violate GIGO.

IIRC, the Dojo calendar widget nudges the date initially and passes
that back to the caller, which is obviously ill-advised (but not to
the guy who patched it apparently). I suppose such comedy is to be
expected from them; after all, they are still sniffing browsers (not
to mention using the infamously broken isArray function all over the
place). Pretty funny that all of their "new" CSS3 trappings use their
IE sniffer. That's not going to be good for IE9. But then, the whole
thing is tangled up with those, so they've got no real shot of making
that behemoth behave in IE9 and continue to work in IE < 9. Quite a
shame as I told them exactly what to do about that a year ago.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,
Thu, 22 Jul 2010 23:13:03, Thomas 'PointedEars' Lahn

Thomas 'PointedEars' Lahn wrote:
[...]
date: new Date(2010, 6, 1)
Careful on this one. In rare cases, in some time zones, this can
underflow to the previous day (and month in this example). Has to do
with DST, IIRC. Of course, that won't matter unless you are going to
display it, convert it to a string, retrieve the day, etc. In other
words, if it will only be used to calculate time spans, it's fine.

I have code that fixes this

<snip>

new Date(2010, 6, 1, 12, 0, 0)
fixes it.

No, if there would be a *general* problem with the call above (and there is
not, possibly borken *tzdata* implementations in the *OS* aside), then your
call would not be a fix; it could, at most, slightly reduce the likelihood
that a problem could occur.

No. JGH's approach fixes *perceived* problems with new Date(2010, 6, 1)
seen by those who forget that the number of seconds in a civil day is
not always 86400.

A better approach for those, who very commonly are not interested in the
actual current time, is to use new Date(Date.UTC(2010, 6, 1)) or
new Date("2010-07-01 00:00 GMT") and to work in GMT (which is faster)
throughout.

 

[David Mark]

In comp.lang.javascript message <[email protected]>,
Thu, 22 Jul 2010 23:13:03, Thomas 'PointedEars' Lahn
<[email protected]> posted:

John G Harris wrote:

David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
[...]
date:    new Date(2010, 6, 1)
Careful on this one.  In rare cases, in some time zones, this can
underflow to the previous day (and month in this example).  Has to do
with DST, IIRC.  Of course, that won't matter unless you are going to
display it, convert it to a string, retrieve the day, etc.  In other
words, if it will only be used to calculate time spans, it's fine.
I have code that fixes this
  <snip>
  new Date(2010, 6, 1,  12, 0, 0)
fixes it.

No, if there would be a *general* problem with the call above (and thereis
not, possibly borken *tzdata* implementations in the *OS* aside), then your
call would not be a fix; it could, at most, slightly reduce the likelihood
that a problem could occur.

No.  JGH's approach fixes *perceived* problems with new Date(2010, 6, 1)
seen by those who forget that the number of seconds in a civil day is
not always 86400.

A better approach for those, who very commonly are not interested in the
actual current time, is to use   new Date(Date.UTC(2010, 6, 1))   or
new Date("2010-07-01 00:00 GMT")   and to work in GMT (which is faster)
throughout.

Of, in many cases, use three numbers. After all, for many
applications, the Date objects add little that couldn't be done with
basic math. Given that performing integer arithmetic is not prone to
sporadic and obscure errors, it's a no-brainer. This was the case
with the widget in question, but the Dojo representative rebuffed the
suggestion with a blanket assertion that Date objects were their "best
bet" for storing dates "over the wire". Some people just aren't cut
for this stuff (and unfortunately, they are usually the ones trying to
write all-powerful monolithic libraries).

 

[Dr J R Stockton]

In comp.lang.javascript message <2fcb945e-b973-4aa5-9fa8-552d82bad8df@n8
g2000prh.googlegroups.com>, Thu, 22 Jul 2010 15:53:39, David Mark

The problem I saw existed in at least one major desktop browser
(latest version at the time) on Windows. We did discuss this problem
here as well (back around October of last year).

If you are referring to Opera, versions before 10.52, to say that the
problem was with new Date(Y, M, D) is over-simplification. The
problem was, in fact, with the calculation of the offset from GMT for
some localities, for the state of which I can think of no polite
description.

See my <URL:http://www.merlyn.demon.co.uk/js-datex.htm#O1051>.

 

[David J Trower]

PointedEars,

Thanks for your help, I was able to take what you provided as a
starting point and have successfully gotten my code to do what I
want. I wouldn't have been able to do that without your helpful
assistance.

Thank you.