Setting new date with offset in days

[Paul E. Schoen]

I am using a JavaScript in a NitroPro PDF application, and I want to be
able to set a date that is a certain number of days ahead or prior to the
present date. I found the conversions from/to UNIX date format in
http://www.merlyn.demon.co.uk/js-date1.htm#CtDC but my script seems to work
a bit strangely:

var sPrompt = app.response("Enter days offset");
var d = new Date();
var tbText = this.getField("Text2_101"); //doc.fieldName
var UnixDays =Math.floor(d/864e5) + sPrompt;
var d1 = new Date((UnixDays)*864e5);
tbText.value = d1.getMonth()+"/"+d1.getDate()+"/"+(d1.getYear()+1900-355);

With an offset of zero(0), this gives 5/23/2009 with today's date of
6/13/2009.

An offset of one (1) gives 5/24/2009, but a negative offset of (-1) gives
NaN/NaN/NaN.

An offset of 9 gives 6/2/2009, but 10 gives 9/21/5559.

An offset of 23 gives a date of 10/3/5559.

I also don't know why I had to subtract 355 years from the getYear()
function.

Is there something wrong in the scripting implementation of NitroPro?

Thanks,

Paul

 

[Lasse Reichstein Nielsen]

I am using a JavaScript in a NitroPro PDF application, and I want to be
able to set a date that is a certain number of days ahead or prior to the
present date. I found the conversions from/to UNIX date format in
http://www.merlyn.demon.co.uk/js-date1.htm#CtDC but my script seems to work
a bit strangely:

var sPrompt = app.response("Enter days offset");

I expect this to produce a string.

var d = new Date();
var tbText = this.getField("Text2_101"); //doc.fieldName
var UnixDays =Math.floor(d/864e5) + sPrompt;

Here you add a string to a number. That converts the number to a
string too, and concatenates the two strings. That's not what you
want.

var d1 = new Date((UnixDays)*864e5);

It might not be safe to do millisecond computations if you want a day
difference (not all days are 864e5 milliseconds long).

Instead you can do:

var sPrompt = app.response("Enter days offset");
var dayDelta = Number(sPrompt);
var d1 = new Date();
d1.setDate(d.getDate() + dayDelta);

tbText.value = d1.getMonth()+"/"+d1.getDate()+"/"+(d1.getYear()+1900-355);

With an offset of zero(0), this gives 5/23/2009 with today's date of
6/13/2009.

An offset of one (1) gives 5/24/2009, but a negative offset of (-1) gives
NaN/NaN/NaN.

Because a string of digits followed by "-1" doesn't convert to a number.

/L

 

[Thomas 'PointedEars' Lahn]

[...] I am using a JavaScript in a NitroPro PDF application, and I want to be
able to set a date that is a certain number of days ahead or prior to the
present date. I found the conversions from/to UNIX date format in
http://www.merlyn.demon.co.uk/js-date1.htm#CtDC

Unnecessary here.

but my script seems to work a bit strangely:

var sPrompt = app.response("Enter days offset");
var d = new Date();
var tbText = this.getField("Text2_101"); //doc.fieldName
var UnixDays =Math.floor(d/864e5) + sPrompt;

I don't know what app.response() really does, but this like looks like a
recipe for disaster. If one operand of `+' is a string (as indicated by the
`s' prefix here), the other operands are converted to string for the purpose
of string concatenation.

var d1 = new Date((UnixDays)*864e5);
tbText.value = d1.getMonth()+"/"+d1.getDate()+"/"+(d1.getYear()+1900-355);

With an offset of zero(0), this gives 5/23/2009 with today's date of
6/13/2009.

Assuming midnight, the date value for "6/13/2009" (2009-06-13) is
1244844000000. Divided by 864e5 equals 14407.916666666666, of which the
floor is 14407. `0' concatenated results in "144070". Multiplication
forces conversion back to number, and 144070 multiplied by 864e5 equals
12447648000000 which is the date value for "Sun Jun 14 2364 02:00:00
GMT+0200 (CEST)" here. As Date.prototype.getYear() is not Y2K-safe, it
returns 464 for that value here. 464 + 1900 - 355 equals 2009. However,
Date.prototype.getMonth() would of course return 5 for June (month offset is
zero-based). The `23' in your result I can't explain yet, but the
difference might be caused by my initial assumption of midnight.

An offset of one (1) gives 5/24/2009, but a negative offset of (-1) gives
NaN/NaN/NaN.

Probably because `d1' stores an invalid date then. The concatenation would
result in "N-0" (with N being a computed integer) which is NaN when
multiplied by anything (here: 864e5) as it cannot be converted to number.

An offset of 9 gives 6/2/2009, but 10 gives 9/21/5559.

An offset of 23 gives a date of 10/3/5559.

ISTM you have your explanation now.

I also don't know why I had to subtract 355 years from the getYear()
function.

Probably you did not need to. Date.prototype.getFullYear() is supported
since JavaScript 1.3 (Netscape 4.0), JScript 3.0 (IE/MSHTML 4.0), ECMAScript
Ed. 3 (2000 CE).

Is there something wrong in the scripting implementation of NitroPro?

Unlikely. There is something wrong with your approach. One computes
a date with offset in days to another date (here: now) as follows:

var d = new Date();
d.setDate(d.getDate() + offset);


HTH

PointedEars

 

[Paul E. Schoen]

I expect this to produce a string.


Here you add a string to a number. That converts the number to a
string too, and concatenates the two strings. That's not what you
want.

I thought JavaScript used the type of the first element of an expression to
make the implicit conversion. At least that's what my book on JScript says.
But it does warn that the safest bet is converting numbers to strings.

It might not be safe to do millisecond computations if you want a day
difference (not all days are 864e5 milliseconds long).

Instead you can do:

var sPrompt = app.response("Enter days offset");
var dayDelta = Number(sPrompt);
var d1 = new Date();
d1.setDate(d.getDate() + dayDelta);



Because a string of digits followed by "-1" doesn't convert to a number.

That helped a lot. But I did have to use the printd function below, as the
getMonth() returned one less than what was correct. I know that months are
zero-based, but it would have been inelegant to make the conversion.

var tbText = this.getField("Text2_101"); //doc.fieldName
var sPrompt = app.response("Enter days offset");
var dayDelta = Number(sPrompt);
var d1 = new Date();
d1.setDate(d.getDate() + dayDelta);
//tbText.value = d1.getMonth()+"/"+d1.getDate()+"/"+(d1.getYear()+1900);
tbText.value = util.printd("mm/dd/yyyy",d1);
tbText.setFocus();

Now I would like to know how to make the value in the textbox update on the
form when it is set. Now I have to click on another text box to see the
updated value. Is there some sort of refresh method?

I tried doing a setFocus to the control as shown above, and it worked, but
the page shifted up so that control was at the top of the window.

Thanks,

Paul

 

[Paul E. Schoen]

[...] I am using a JavaScript in a NitroPro PDF application, and I want
to be
able to set a date that is a certain number of days ahead or prior to
the
present date. I found the conversions from/to UNIX date format in
http://www.merlyn.demon.co.uk/js-date1.htm#CtDC

Unnecessary here.

but my script seems to work a bit strangely:

var sPrompt = app.response("Enter days offset");
var d = new Date();
var tbText = this.getField("Text2_101"); //doc.fieldName
var UnixDays =Math.floor(d/864e5) + sPrompt;

I don't know what app.response() really does, but this like looks like a
recipe for disaster. If one operand of `+' is a string (as indicated by
the
`s' prefix here), the other operands are converted to string for the
purpose
of string concatenation.

app.response() is a dialog box that apparently takes the place of prompt(),
which does not seem to be available here.

Assuming midnight, the date value for "6/13/2009" (2009-06-13) is
1244844000000. Divided by 864e5 equals 14407.916666666666, of which the
floor is 14407. `0' concatenated results in "144070". Multiplication
forces conversion back to number, and 144070 multiplied by 864e5 equals
12447648000000 which is the date value for "Sun Jun 14 2364 02:00:00
GMT+0200 (CEST)" here. As Date.prototype.getYear() is not Y2K-safe, it
returns 464 for that value here. 464 + 1900 - 355 equals 2009. However,
Date.prototype.getMonth() would of course return 5 for June (month offset
is
zero-based). The `23' in your result I can't explain yet, but the
difference might be caused by my initial assumption of midnight.


Probably because `d1' stores an invalid date then. The concatenation
would
result in "N-0" (with N being a computed integer) which is NaN when
multiplied by anything (here: 864e5) as it cannot be converted to number.


ISTM you have your explanation now.


Probably you did not need to. Date.prototype.getFullYear() is supported
since JavaScript 1.3 (Netscape 4.0), JScript 3.0 (IE/MSHTML 4.0),
ECMAScript
Ed. 3 (2000 CE).


Unlikely. There is something wrong with your approach. One computes
a date with offset in days to another date (here: now) as follows:

var d = new Date();
d.setDate(d.getDate() + offset);

That works very well, and thanks for your analysis of the problem. But I
was under the impression that getDate() returned the day of the month, from
1 to 31. At least that's what it says in my book on "Using JScript". But
it's copyright 1997, so maybe I need a new reference

Paul

 

[Evertjan.]

Paul E. Schoen wrote on 14 jun 2009 in comp.lang.javascript:

That works very well, and thanks for your analysis of the problem. But
I was under the impression that getDate() returned the day of the
month, from 1 to 31.

So getDate() does.

You will only need to update your impression of setDate().

At least that's what it says in my book on "Using
JScript".

This NG gives you the most up to date info,
including factual behavour not found in any reference.

See "Browser Documentation" in the NG FAQ for links to refeences

But it's copyright 1997, so maybe I need a new reference

I don't see a more than circiumstantial connection to a copyright date.

 

[Thomas 'PointedEars' Lahn]

I thought JavaScript used the type of the first element of an expression to
make the implicit conversion. At least that's what my book on JScript says.

Throw it away ...

But it does warn that the safest bet is converting numbers to strings.

.... and instead of relying on books (there are no good books out there and
making bets, read the ECMAScript Language Specification, Edition 3 Final,
section 11.6.1, The Addition operator, among others.

[...]
That helped a lot. But I did have to use the printd function below,

There is no function below.

as the getMonth() returned one less than what was correct. I know that
months are zero-based, but it would have been inelegant to make the
conversion.

Do you want an elegant or a working solution?

var tbText = this.getField("Text2_101"); //doc.fieldName
var sPrompt = app.response("Enter days offset");
var dayDelta = Number(sPrompt);
var d1 = new Date();
d1.setDate(d.getDate() + dayDelta);
//tbText.value = d1.getMonth()+"/"+d1.getDate()+"/"+(d1.getYear()+1900);
tbText.value = util.printd("mm/dd/yyyy",d1);
tbText.setFocus();

Now I would like to know how to make the value in the textbox update on the
form when it is set. Now I have to click on another text box to see the
updated value.

Be more specific. You are already updating the text box when it is set.

That said, you shouldn't assume everybody understands the date format you
are familiar with. Your best chance of providing an understandable date
control is using either the ISO date format YYYY-MM-DD, or three controls
each, for i18n'd YYYY (input or select), MMM(M) (select), and D(D) (input or
select), preferably in L10n'd order. It is a good idea to provide a
calendar widget with it.

Is there some sort of refresh method?

No.


PointedEars

 

[Lasse Reichstein Nielsen]

news:[email protected]...

I thought JavaScript used the type of the first element of an expression to
make the implicit conversion. At least that's what my book on JScript says.

Then the book is wrong.
If either operand of a plus is a string, the other is converted to a string
as well, and the plus means string concatenation.
Otherwise, both are converted to numbers, and the plus is numerical addition.

But it does warn that the safest bet is converting numbers to strings.

And strings to numbers, which is much more often the problem.

That helped a lot. But I did have to use the printd function below, as the
getMonth() returned one less than what was correct.

You could add one to the result of getMonth() yourself
I would prefer the utility function anyway, since it probably handles
four-digit years better.

I know that months are zero-based, but it would have been inelegant
to make the conversion.

It appens a lot, so it's not like it would confuse most Javascript
programmers to see (d.getMonth() + 1).

Now I would like to know how to make the value in the textbox update on the
form when it is set. Now I have to click on another text box to see the
updated value. Is there some sort of refresh method?

That would be PDF-script specific (i.e., I have absolutely no clue).

I tried doing a setFocus to the control as shown above, and it worked, but
the page shifted up so that control was at the top of the window.

Maybe you can loose the focus instead of setting it?

/L

 

[Thomas 'PointedEars' Lahn]

Paul E. Schoen wrote:

[fixed borken quotes]

var sPrompt = app.response("Enter days offset");
[...]
var UnixDays =Math.floor(d/864e5) + sPrompt;

I don't know what app.response() really does, but this like looks like a
recipe for disaster. If one operand of `+' is a string (as indicated by
the `s' prefix here), the other operands are converted to string for the
purpose of string concatenation.

app.response() is a dialog box that apparently takes the place of prompt(),
which does not seem to be available here.

So it would return a string value, as I suspected.

[...] One computes a date with offset in days to another date
here: now) as follows:

var d = new Date();
d.setDate(d.getDate() + offset);

That works very well, and thanks for your analysis of the problem. But I
was under the impression that getDate() returned the day of the month, from
1 to 31.

Or 1 to 28, or 1 to 29, or 1 to 30; depending on the month, of course.

At least that's what it says in my book on "Using JScript". But
it's copyright 1997, so maybe I need a new reference

That would certainly be a good idea, especially as it covers only one very
old ECMAScript implementation (the year indicates JScript 1.0 to 3.0 as of
IE/MSHTML 3.0 to 4.0¹; current is 5.6+ as of IE 6+). Avoid books, though,
use the resources linked in the FAQ instead.

Nevertheless, your book is almost right about this for a change. However,
Date.prototype.*setDate*() considers overflows and underflows, and computes
the date value accordingly. (For example, d.setDate(-1) sets `d' to the
last day of the previous month of its current date value.) See ES3F, 15.9.5.36.

Thank you in advance for quoting only the minimum of relevant parts next
time. <http://jibbering.com/faq/#posting> pp.

And you want to use a better newsreader:

<http://insideoe.com/>
<http://getthunderbird.com/>


PointedEars
___________
¹ <http://PointedEars.de/scripts/test/es-matrix/#jscript>
(not yet up-to-date, but sufficient here)

 

[Thomas 'PointedEars' Lahn]

[...] However, Date.prototype.*setDate*() considers overflows and
underflows, and computes the date value accordingly. (For example,
d.setDate(-1) sets `d' to the last day of the previous month of its
current date value.) See ES3F, 15.9.5.36.

Must be either d.setDate(0) or "the day before the last day ..." to be correct.


PointedEars

 

[Dr J R Stockton]

I am using a JavaScript in a NitroPro PDF application, and I want to be
able to set a date that is a certain number of days ahead or prior to the
present date. I found the conversions from/to UNIX date format in
http://www.merlyn.demon.co.uk/js-date1.htm#CtDC

You should have read onwards in the page's Index : the next major
section is "Date/Time Incrementing/Decrementing" and includes what you
want, for civil days. For GMT/UTC days, use the UTC routines.

Code in Section "Day Counts", which contains #CtDC, can be combined to
do what you ask for, but that would be like going from Boston to
Gloucester via Aberystwyth,

 

[Dr J R Stockton]

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

That works very well, and thanks for your analysis of the problem. But I
was under the impression that getDate() returned the day of the month, from
1 to 31. At least that's what it says in my book on "Using JScript". But
it's copyright 1997, so maybe I need a new reference

If you are interested in JScript, you should be using a JScript
newsgroup.

When citing a book, it is helpful to name the author. The owner is
largely irrelevant.

The book is dated; but evidently you can still learn from it (unless it
is unreasonably bad).

 

[Thomas 'PointedEars' Lahn]

Paul E. Schoen posted:

If you are interested in JScript, you should be using a JScript
newsgroup.

Rubbish. The record shows that all ECMAScript implementations are on-topic
here (however, one would be wise to use macromedia.ALL for ActionScript as
questions are likely to be Flash-specific). For discussing the
peculiarities of JScript, Microsoft's ECMAScript implementation, one does
not need to post to microsoft.public.dotnet.languages.jscript,
microsoft.public.inetsdk.programming.scripting.jscript, or
microsoft.public.scripting.jscript (those are the groups having `jscript' in
their names).

See also: <http://jibbering.com/faq/#appropriateQuestions>


PointedEars

 

[Paul E. Schoen]

Rubbish. The record shows that all ECMAScript implementations are
on-topic
here

See also: <http://jibbering.com/faq/#appropriateQuestions>

The book I have is a Que Corp Special Edition by Mark Reynolds.

The more I try to understand the various scripting languages the more
complex it seems to become. I am reasonably proficient in Borland Delphi,
and C, and assembly, for compiling executables on the Windows platform and
also for microcontrollers, but when it comes to scripting I have used
application scripts based on VBA and some JavaScript that runs in a
browser, and more recently the JavaScript for PDF as implemented in
NitroPro. I have also written some stand-alone scripts that use the Windows
Scripting Host, but that seems to be totally different so that I need to
use WScript.Echo for the equivalent of a JavaScript alert(), and I have
also run into inconsistencies such as the replacement of prompt() with
app.response() in the Nitro implementation.

I'm really quite confused by the differences in Java, JavaScript, JScript,
and WScript, and the way they work in browsers, applications, PDFs, or on
the Windows Script Host. I also don't know if the Java runtime environment
is used for scripts. And I have found some examples (such as a dat picker)
that will run on Mozilla Firefox but not IE7, or vise versa.

Debugging is another issue. In Firefox I have Firebug which works very
nicely as I am used to the debugging environments of Delphi and MPLAB for
microcontroller code, but IE7 just gives an "error on page" with no
reference to where it occurs. In the Windows Script Host at least it gives
a line number and some meaningful error message such as "method not
supported". And in the Nitro PDF the script just stops running when an
error occurs.

I know these are a lot of questions about a number of different topics, but
hopefully you can see why I am confused and point me in the right
direction(s).

Thanks,

Paul

 

[Michael J. Ryan]

Rubbish. The record shows that all ECMAScript implementations are on-topic
here (however, one would be wise to use macromedia.ALL for ActionScript as
questions are likely to be Flash-specific). For discussing the
peculiarities of JScript, Microsoft's ECMAScript implementation, one does
not need to post to microsoft.public.dotnet.languages.jscript,
microsoft.public.inetsdk.programming.scripting.jscript, or
microsoft.public.scripting.jscript (those are the groups having `jscript' in
their names).

See also: <http://jibbering.com/faq/#appropriateQuestions>

Aside from their ActiveXObject and the Enumeration object, JScript is pretty
compliant. Though questions related to ActiveX in js or wsh would probably be
better served elsewhere..

 

[Paul E. Schoen]

Paul E. Schoen wrote:

That does not sound like a symptom of understanding.

I think my main problem has been the concept of what is actually used to
run (or host) the script. Particularly the differences in the WSH, browsers
(with HTML), and individual applications. And also the peculiarities of the
WSH which can run both JScript and WScript (or VB Script).

The - alert - method is not part of javascript, it is a method provided
by browser hosts. Other host environments may or may not provide that
method (many do not) and may or may not provide alternatives.

I suppose this method and the related confirm() and prompt() are actually
window objects (or perhaps app objects.

Isn't WScript the windows program (or one of the two windows programs)
that provides the host environment for Windows scripting host, and not a
scripting language at all.

The WSH http://support.microsoft.com/kb/188135 apparently runs either .js
or .vbs or .wbs scripts. But apparently the JavaScript objects are much
more limited.

Probably bad books (documentation/web resorces, etc.).

Mostly the differences in the script hosts, and what objects and methods
are supported. It seems that JavaScript or JScript is best used in a web
browser environment, or when necessary in PDFs where VBA is not supported.
Otherwise probably VBS would be better for utility scripts that run on the
WSH. But it's difficult to switch back and forth between the C-like JS and
the less structured VB.

First read the group's FAQ.

<URL: http://jibbering.com/faq/ >

I found a lot of good information there, but mostly my problems were due to
limitations of the host and the object models they provide. I now
understand that they are not strictly part of the JavaScript language
itself. I think that clears things up. Thanks.

Paul

 

[Thomas 'PointedEars' Lahn]

I think my main problem has been the concept of what is actually used to
run (or host) the script. Particularly the differences in the WSH, browsers
(with HTML), and individual applications. And also the peculiarities of the
WSH which can run both JScript and WScript (or VB Script).

As Richard already hinted at, contrary to what you think, WScript is _not_
another programming language. It is an API that can be used with several
programming languages, among them JScript and VBScript, and in several
runtime environments, among them WSH scripts (native) and MSHTML (using an
ActiveX/COM control in a privileged environment, IIRC).

I suppose this method and the related confirm() and prompt() are actually
window objects (or perhaps app objects.

The owner of these properties is documented to be a Window object, however
it is possible that the Global Object is augmented with them by the runtime
environment. The properties themselves are implemented either as callable
host objects or native Function objects, whereas the former is more likely
in MSHTML.

The WSH http://support.microsoft.com/kb/188135 apparently runs either .js
or .vbs or .wbs scripts.

You mean .wsf instead?

But apparently the JavaScript objects are much more limited.

First of all, JScript, not JavaScript. Second, no. The API is the same
regardless of the programming language.

I found a lot of good information there, but mostly my problems were due to
limitations of the host and the object models they provide. I now
understand that they are not strictly part of the JavaScript language
itself.

They are _not_ part of the JavaScript language (anymore). Period.
AFAIK they have never been part of the JScript language.
They have definitely never been part of the ECMAScript language and its
other implementations.

I think that clears things up.

I don't think so.

Thanks.

You're welcome.


PointedEars

 

[Paul E. Schoen]

You mean .wsf instead?

Yes. From: http://en.wikipedia.org/wiki/VBScript:

Usual file extensions: .vbs, .asp

VBScript .vbs files can be included in two other types of scripting files:
..wsf files, which are styled after XML; and .hta files, which are styled
after HTML.

I don't think so.

Well, at least now I know what code to use (and not use) for various
purposes. I will need to use JavaScript for PDFs, at least for NitroPro and
probably Adobe 9, depending on which I decide to get. For simple windows
automation I can use the .js scripts I already have, but VBScripts may be
better if I need to do something more interactive (using an InputBox, eg).
For HTML I would surely use JavaScript or JScript. And for applications
such as Access and Excel I will need to use VBA.

But I still prefer to use Borland Delphi for most things that run on the
local machine. And I have written applications that use automation to
interface to properties, methods, and events of other applications,
particularly PADS Logic and PADS Layout.

Paul

 

[Dr J R Stockton]

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

It seems that JavaScript or JScript is best used in a web
browser environment, or when necessary in PDFs where VBA is not supported.
Otherwise probably VBS would be better for utility scripts that run on the
WSH.

VBS is much more commonly used; that does not mean that it is actually
better. It does mean that there are more experts in the WSH VBS groups
than in the WSH JS ones.

In another article :

But I still prefer to use Borland Delphi for most things that run on
the local machine.

Very wise; though, for work within its capability, Borland Pascal 7
DOS/DPMI mode is nicer. See sig,

 

[Paul E. Schoen]

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


VBS is much more commonly used; that does not mean that it is actually
better. It does mean that there are more experts in the WSH VBS groups
than in the WSH JS ones.

Is there a group for the WSH?

My main criterion for saying VBS is better is only because it seems to
offer more capability within the WSH environment. Particularly I want the
ability to accept user input via an InputBox() or prompt(). It seems odd
that the WSH will provide that ability for a VB script but not for a JS
script, even though I believe the same application is used for both. And a
JScript can access the FSO to do file operations using the WSH, and it uses
a WScript.echo() as a replacement for prompt().

My confusion has probably been based more on the peculiarities of the WSH
and supported objects, than the JavaScript or JScript language itself.

In another article :


Very wise; though, for work within its capability, Borland Pascal 7
DOS/DPMI mode is nicer. See sig,

I would assume, however, that the program generates an MSDOS executable
that runs in a DOS window. This is not so terrible, but I like the idea of
using the Windows GUI which is offered by scripting. For very simple
windows automation, such as saving a list of files to a folder, I could
just as well use a .BAT file. That was the purpose of a .JS script I wrote
some time ago. But I was surprised to find that the WSH did not provide any
form of user text input. And it was also a surprise to find that Nitro PDF
used a different set of objects that included the usual alert() but
substituted response() for prompt().

As discussed in the Turbo Pascal FAQ
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip>, the bottom line is really
all about accomplishing a needed task in the most efficient manner
possible, with the criteria of portability, time to program, and ease of
use being most important. But for purists it is much more about the
language itself, elegance, programming style, and other factors which are
process oriented rather than results oriented.

Thanks,

Paul