adding to a ddmmyyyy date

[ginajohnst]

Hi All.

I'm having a problem adding days to a date.

My date is in the string format dd/mm/yyyy eg. 23/08/2007 in my
form field.

I can't work out how to add 50 days to that date and then write it to
another form field.

Any help would be appreciated.

 

[David Mark]

Hi All.

I'm having a problem adding days to a date.

My date is in the string format dd/mm/yyyy eg. 23/08/2007 in my
form field.

I can't work out how to add 50 days to that date and then write it to
another form field.

Any help would be appreciated.

Which part can't you figure out? See the FAQ for date manipulation.
To change a form element's value, set its value property.

 

[Thomas 'PointedEars' Lahn]

I'm having a problem adding days to a date.

My date is in the string format dd/mm/yyyy eg. 23/08/2007 in my
form field.

I can't work out how to add 50 days to that date and then write it to
another form field.

Quickhack:

var
a = formField.value.split("/"),
d = new Date(
parseInt(a[2], 10), parseInt(a[1], 10), parseInt(a[0], 10) + 50);

anotherFormField.value =
String(d.getDate() * 1e6 + d.getMonth() * 1e4 + d.getFullYear())
.replace(/(\d\d)(\d\d)(\d{4})/, "$1/$2/$3");

However, you better separate the components, one `input' or `select' element
for each one, in order to make your date input unambiguous.


PointedEars

 

[ginajohnst]

I'm having a problem adding days to a date.

My date is in the string format dd/mm/yyyy eg. 23/08/2007 in my
form field.

I can't work out how to add 50 days to that date and then write it to
another form field.

Quickhack:

var
a = formField.value.split("/"),
d = new Date(
parseInt(a[2], 10), parseInt(a[1], 10), parseInt(a[0], 10) + 50);

anotherFormField.value =
String(d.getDate() * 1e6 + d.getMonth() * 1e4 + d.getFullYear())
.replace(/(\d\d)(\d\d)(\d{4})/, "$1/$2/$3");

However, you better separate the components, one `input' or `select' element
for each one, in order to make your date input unambiguous.

Hi Thomas.

Thanks for that. I'll make sure that I understand it completely
before I use your example.

Thanks again.

 

[Lee]

ginajohnst said:

I'm having a problem adding days to a date.

My date is in the string format dd/mm/yyyy eg. 23/08/2007 in my
form field.

I can't work out how to add 50 days to that date and then write it to
another form field.

Quickhack:

var
a = formField.value.split("/"),
d = new Date(
parseInt(a[2], 10), parseInt(a[1], 10), parseInt(a[0], 10) + 50);

anotherFormField.value =
String(d.getDate() * 1e6 + d.getMonth() * 1e4 + d.getFullYear())
.replace(/(\d\d)(\d\d)(\d{4})/, "$1/$2/$3");

However, you better separate the components, one `input' or `select' element
for each one, in order to make your date input unambiguous.

Hi Thomas.

Thanks for that. I'll make sure that I understand it completely
before I use your example.

Once you understand it completely, you should be able to come up
with a much simpler solution that actually works.

http://docs.sun.com/source/816-6408-10/date.htm


--

 

[Dr J R Stockton]

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

Quickhack:

but not well tested. It gives
23/02/2007 + 50 -> 12/04/2007
23/08/2007 + 50 -> 12/10/2007

But February is shorter than August, and should give days 3 more.

var
a = formField.value.split("/"),
d = new Date(
parseInt(a[2], 10), parseInt(a[1], 10), parseInt(a[0], 10) + 50);

d = new Date(a[2], a[1]-1, a[0]+50) // suffices

One can replace, in this context, parseInt by unary +; and that will in
context be effectively implicit.

anotherFormField.value =
String(d.getDate() * 1e6 + d.getMonth() * 1e4 + d.getFullYear())
.replace(/(\d\d)(\d\d)(\d{4})/, "$1/$2/$3");

Do you find that better than, with suitable LZ,

anotherFormField.value =
LZ(d.getDate()) + '/' + LZ(d.getMonth()+1) + '/' + d.getFullYear()

// ??

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

 

[Dr J R Stockton]

Once you understand it completely, you should be able to come up
with a much simpler solution that actually works.

http://docs.sun.com/source/816-6408-10/date.htm

/* There must be a nicer-looking version of that page, with a margin */
/* Note its error in a line starting like <tt>milliseconds</tt> */
/* They seem to ignore that UT != UTC */

Which parts of that page d0 you believe to deal with the reading and
writing of non-FFF numeric date strings??

 

[ginajohnst]

ginajohnst said:

Once you understand it completely, you should be able to come up
with a much simpler solution that actually works.

http://docs.sun.com/source/816-6408-10/date.htm

Yep. I've ended up with this so far and I think a bit of testing will
give me the result I want.

var a = document.getElementById('date1').value.split("/");

d = new Date((a[2]), (a[1])-1, (a[0]));
d = new Date(d.getTime() + 50*24*60*60*1000);

document.getElementById('date2').value = String(d.getDate() + '/' +
(d.getMonth()+1) + '/' + d.getFullYear());

 

[Evertjan.]

ginajohnst wrote on 08 aug 2007 in comp.lang.javascript:

Yep. I've ended up with this so far and I think a bit of testing will
give me the result I want.

var a = document.getElementById('date1').value.split("/");

d = new Date((a[2]), (a[1])-1, (a[0]));

too much ()()()

var d

d = new Date(d.getTime() + 50*24*60*60*1000);

safer:
d.setTime(d.getTime() + 50*24*60*60*1000);
or, also easier:
d.setDate(d.getDate() + 50);

document.getElementById('date2').value = String(d.getDate() + '/' +
(d.getMonth()+1) + '/' + d.getFullYear());

No need for String(), the conversion is automatic.

I would add an extra zero on the single figure dates and months.

Try [leaving the DOM part for you to insert]:

==========================================
<script type='text/javascript'>

var a = '22/11/2006'.split("/");

var d = new Date(a[2], a[1]-1, a[0]);
d.setDate(d.getDate() + 50);

var r =
T(d.getDate())+'/'+T(d.getMonth()+1)+'/'+d.getFullYear();

alert(r);

function T(x){
return (x>9)?x'0'+x);
};

</script>
===========================================

 

[Thomas 'PointedEars' Lahn]

My solution works alright. If one had tested it, as I did, one would have
known. But what to expect from a noname person with headers disregarding
Internet standards, Netiquette and their ISP's terms of service?

Yep. I've ended up with this so far and I think a bit of testing will
give me the result I want.

var a = document.getElementById('date1').value.split("/");

Your continued unnecessary mixing of DOM 2 features with features
originating from DOM 0 is giving me headaches. As it should give you.

d = new Date((a[2]), (a[1])-1, (a[0]));

`08' may be parsed as an invalid octal value, hence parseInt(, 10);
Without parseInt(), the parens add no more than further confusion.

d = new Date(d.getTime() + 50*24*60*60*1000);

Won't work as expected. I'm sure John will happily point out why.

I can't think of a valid reason why

d = new Date(..., ..., parseInt(a[0], 10) + 50);

shouldn't be used.

document.getElementById('date2').value = String(d.getDate() + '/' +
(d.getMonth()+1) + '/' + d.getFullYear());

String conversion is unnecessary with that error-prone an approach.


PointedEars

 

[Thomas 'PointedEars' Lahn]

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

Quickhack:

but not well tested.

Hence *quick**hack*.

It gives
23/02/2007 + 50 -> 12/04/2007
23/08/2007 + 50 -> 12/10/2007

But February is shorter than August, and should give days 3 more.

Confirmed in FF 2.0.0.6 :-/ But where is the error here? If it isn't mine,
can someone quickly point out anything in ES3 that specifies it?

var
a = formField.value.split("/"),
d = new Date(
parseInt(a[2], 10), parseInt(a[1], 10), parseInt(a[0], 10) + 50);

d = new Date(a[2], a[1]-1, a[0]+50) // suffices

Would that not have the same February problem as my solution?

One can replace, in this context, parseInt by unary +; and that will in
context be effectively implicit.

I had thought about that, but what about octals?

Do you find that better than, with suitable LZ,

anotherFormField.value =
LZ(d.getDate()) + '/' + LZ(d.getMonth()+1) + '/' + d.getFullYear()

// ??

Hm. No. I just liked your previous solution and had my quickhack based on it.


PointedEars

 

[Lee]

Thomas 'PointedEars' Lahn said:

My solution works alright. If one had tested it, as I did, one would have
known. But what to expect from a noname person with headers disregarding
Internet standards, Netiquette and their ISP's terms of service?

You think you tested that?

Can you explain how it can work properly when you don't subtract
one from the month before passing it to the Date constructor?

Can you explain how your ludicrous multiplication method works
if the resulting date is earlier than the 10th of the month?

Try these inputs, genius:
01/11/2008
13/11/2008


--

 

[Dr J R Stockton]

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

safer:
d.setTime(d.getTime() + 50*24*60*60*1000);

Better, yes; but why safer?

or, also easier:
d.setDate(d.getDate() + 50);

That's also safer. Starting at Saturday 2007-03-24 23:30, the first
gives us a Monday and the second a Sunday. 50 days are 7 weeks plus ONE
day.



Re another article : parseInt(S) for S being "08" or "09" gives zero
(the standard reluctantly allows that); so, in this context, if parseInt
is used then it does need ', 10'.

But without parseInt, "08" and "09" are taken as eight and nine;
although "077" is sixty-three, "078" is seventy-eight - at least,
wherever I've tried it. That seems compatible with ISO/IEC 16262 B.1.

Javascript lacks specific syntax for creating a Date Object of a given
Ordinal Date; it does not need any, since new Date(YYYY, 0, DDD)
suffices. For DDD, parseInt(DDD, 10) seems essential.

new Date(2007, 0, 077) // Mar 4
new Date(2007, 0, 078) // Mar 19

Similar considerations apply to YYYY - parseInt is necessary unless most
years before 800 will definitely not be used.

 

[Evertjan.]

Dr J R Stockton wrote on 09 aug 2007 in comp.lang.javascript:

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


Better, yes; but why safer?

Because this

d = new Date((a[2]), (a[1])-1, (a[0]));
d = new Date(d.getTime() + 50*24*60*60*1000);

is less understandable, so is bound to have more mistakes made.

Pentakosta [Gr., 50] gives a perfect Pesach to Shavuot+1 arythmatic.

That's also safer. Starting at Saturday 2007-03-24 23:30, the first
gives us a Monday and the second a Sunday. 50 days are 7 weeks plus ONE
day.

Yes, indeed!

 

[Lee]

Dr J R Stockton said:

/* There must be a nicer-looking version of that page, with a margin */
/* Note its error in a line starting like <tt>milliseconds</tt> */
/* They seem to ignore that UT != UTC */

Which parts of that page d0 you believe to deal with the reading and
writing of non-FFF numeric date strings??

The information about the constructor and the various setters
and getters seemed useful. The question involved more than
simply reading and writing date strings.


--

 

[Dr J R Stockton]

Thomas 'PointedEars' Lahn said:
Can you explain how your ludicrous multiplication method works
if the resulting date is earlier than the 10th of the month?

The multiplication method is currently good for generating YYYYMMDD.

It is not good for DDMMYYYY or 8-digit FFF.

OTOH, given that separators are required, consider

d = new Date("1234/01/02") // 1234 Jan 2
X =
String(d.getFullYear()*1e4 + d.getMonth()*1e2 + d.getDate() + 100)
.replace(/(\d{4})(\d\d)(\d\d)/, "$3/$2/$1");

Change the \d{4} to \d+ and the code will be shorter and last longer.

 

[Thomas 'PointedEars' Lahn]

Re another article :

While it may be time-saving for you, it would be polite towards the author
of the article, the potential reader, and prudent in general (e.g. in order
not to demonstrate usually inappropriate practice to the uninitiated by a
regular) if you posted a followup to the article you are referring to, in
which you quoted the relevant parts you are referring to, instead.

parseInt(S) for S being "08" or "09" gives zero (the standard
reluctantly allows that); so, in this context, if parseInt
is used then it does need ', 10'.

But without parseInt, "08" and "09" are taken as eight and nine;
although "077" is sixty-three, "078" is seventy-eight - at least,
wherever I've tried it. That seems compatible with ISO/IEC 16262 B.1.

I don't know what ISO/IEC 16262 B.1 says (I won't spend the money required
in order to read it), but if that international standard says the same as
section B.1 of the (freely available) European standard ECMA-262-3 (which
was later approved as ISO/IEC 16262), then the observed behavior would not
be compatible with the compatibility grammar defined there:

| B.1 Additional Syntax
|
| Past editions of ECMAScript have included additional syntax and semantics
| for specifying octal literals and octal escape sequences. These have been
| removed from this edition of ECMAScript. This non-normative annex presents
| uniform syntax and semantics for octal literals and octal escape sequences
| for compatibility with some older ECMAScript programs.
|
| B.1.1 Numeric Literals
|
| The syntax and semantics of section 7.8.3 can be extended as follows:
|
| *Syntax*
|
| NumericLiteral ::
| DecimalLiteral
| HexIntegerLiteral
| OctalIntegerLiteral
|
| OctalIntegerLiteral ::
| 0 OctalDigit
| OctalIntegerLiteral OctalDigit
|
| *Semantics*
|
| • The MV of NumericLiteral :: OctalIntegerLiteral is the MV of
| OctalIntegerLiteral.
| • The MV of OctalDigit :: 0 is 0.
| • The MV of OctalDigit :: 1 is 1.
| • The MV of OctalDigit :: 2 is 2.
| • The MV of OctalDigit :: 3 is 3.
| • The MV of OctalDigit :: 4 is 4.
| • The MV of OctalDigit :: 5 is 5.
| • The MV of OctalDigit :: 6 is 6.
| • The MV of OctalDigit :: 7 is 7.
| • The MV of OctalIntegerLiteral :: 0 OctalDigit is the MV of OctalDigit.
| • The MV of OctalIntegerLiteral :: OctalIntegerLiteral OctalDigit is
| (the MV of OctalIntegerLiteral times 8) plus the MV of OctalDigit.

Whereas the MV is defined as follows:

| 7.8.3.
|
| A numeric literal stands for a value of the Number type. This value is
| determined in two steps: first, a mathematical value (MV) is derived from
| the literal; [...]

Without a closer look, one could then easily conclude that 08 would be
parsed as a DecimalLiteral and 077 be parsed as an OctalIntegerLiteral.
However, that possibility is explicitly excluded by the grammar:

| 7.8.3 Numeric Literals
|
| Syntax
|
| DecimalLiteral ::
| DecimalIntegerLiteral . DecimalDigitsopt ExponentPartopt
| . DecimalDigits ExponentPartopt
| DecimalIntegerLiteral ExponentPartopt
|
| DecimalIntegerLiteral ::
| 0
| NonZeroDigit DecimalDigitsopt
|
| DecimalDigits ::
| DecimalDigit
| DecimalDigits DecimalDigit
|
| DecimalDigit :: one of
| 0 1 2 3 4 5 6 7 8 9
|
| NonZeroDigit :: one of
| 1 2 3 4 5 6 7 8 9

So if e.g. +"08" (or 08) resulted in 8, but +"077" (or 077) resulted in 63,
then this behavior could only be one backed up by

| 2 Conformance
|
| [...] A conforming implementation of ECMAScript is permitted to support
| program and regular expression syntax not described in this specification.

Which would be precisely the reason why I would use parseInt(..., 10) here.

Incidentally, Firefox 2.0.0.6 gives

| Warning: 08 is not a legal ECMA-262 octal constant

Javascript lacks specific syntax for creating a Date Object of a given
Ordinal Date;

Define "Ordinal Date". If you mean something like the number of
milliseconds since the beginning of the UNIX era, then

new Date(timestamp)

where timestamp is that number, works in JavaScript (and JScript, Opera
ECMAScript and KJS), and is specified in ES3:

| 15.9.3.2 new Date (value):
|
| The [[Prototype]] property of the newly constructed object is set to the
| original Date prototype object, the one that is the initial value of
| Date.prototype (section 15.9.4.1).
|
| The [[Class]] property of the newly constructed object is set to "Date".
|
| The [[Value]] property of the newly constructed object is set as follows:
|
| 1. Call ToPrimitive(value).
| 2. If Type(Result(1)) is String, then go to step 5.
| 3. Let V be ToNumber(Result(1)).
| 4. Set the [[Value]] property of the newly constructed object
| to TimeClip(V) and return.
| 5. [...]

Whereas the [[Value]] property of a Date object is defined implicitly as
follows:

| 15.9.1.1 Time Range
|
| Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC.
| Leap seconds are ignored. It is assumed that there are exactly 86,400,000
| milliseconds per day. ECMAScript number values can represent all
^^^^^^
| integers from –9,007,199,254,740,991 to 9,007,199,254,740,991; this range
| suffices to measure times to millisecond precision for any instant that is
| within approximately 285,616 years, either forward or backward, from 01
| January, 1970 UTC.
|
| The actual range of times supported by ECMAScript Date objects is slightly
| smaller: exactly –100,000,000 days to 100,000,000 days measured relative
| to midnight at the beginning of 01 January, 1970 UTC. This gives a range
| of 8,640,000,000,000,000 milliseconds to either side of 01 January, 1970
| UTC.
|
| The exact moment of midnight at the beginning of 01 January, 1970 UTC is
| represented by the value +0.


PointedEars

 

[Dr J R Stockton]

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

Dr J R Stockton wrote:

I don't know what ISO/IEC 16262 B.1 says (I won't spend the money required
in order to read it),

Since it is available free of charge in PDF, that seems rather
unreasonable of you. As the PDF is linked from the ISO site, one can
presume that it is legitimate. A well-maintained FAQ would have a link
to it by now; I have arranged that the URL is easily enough found,
though there's a plain route to it from the ISO page about 16262.

It does not use the same font as the ECMA one, so there's a choice.

It does, however, only have one section 15.9.1.9.



If, before reappearing here, you had read all that had been posted here
since you departed (and reading ancient material has been your forte),
you would have known most of that.

Define "Ordinal Date". If you mean something like the number of
milliseconds since the beginning of the UNIX era, then

It is defined in ISO 8601, which is IIRC released as an EN and possibly
a DIN. Alas, 8601 is AFAIK not free (unlike 8602); but the definition
is easily found by Google.

If you had not snipped the rest of that sentence of mine, I would not
have had to repeat that it went
From that, you should be able to deduce what an Ordinal Date is. The
examples that followed would have confirmed a correct hypothesis.


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

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Fri, 10 Aug 2007 21:04:47, Dr J R Stockton

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


It is defined in ISO 8601, which is IIRC released as an EN and possibly
a DIN. Alas, 8601 is AFAIK not free (unlike 8602); but the definition
is easily found by Google.

Correction : I had forgotten that ISO 8601:2004 was in fact available
free in PDF, from ISO, <http://isotc.iso.org/livelink/livelink?func=ll&o
bjId=4020763&objAction=browse&sort=name> probably; and from OMG -- links
are on my site, but I forget which I actually used. It seems that ISO
do allow one to pay for the paper version and for the PDF, if one so
wishes.

 

[Thomas 'PointedEars' Lahn]

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

I don't know what ISO/IEC 16262 B.1 says (I won't spend the money required
in order to read it),

Since it is available free of charge in PDF, that seems rather
unreasonable of you. As the PDF is linked from the ISO site, one can
presume that it is legitimate. [...]

Thanks. Either I have overlooked it all the time, or they have added that
recently. IIRC there was no such link last time I checked.

JFTR: ISO/IEC 16262, Appendix B.1 and subsection 7.8.3, say the same here as
ECMA-262, Appendix B.1 and subsection 7.8.3, do. Therefore, I repeat what
you omitted from my posting (without marking the omission):

So if e.g. +"08" (or 08) resulted in 8, but +"077" (or 077) resulted in
63, then this behavior could only be one backed up by

| 2 Conformance
|
| [...] A conforming implementation of ECMAScript is permitted to support
| program and regular expression syntax not described in this
| specification.

Which would be precisely the reason why I would use parseInt(..., 10)
here.

Incidentally, Firefox 2.0.0.6 gives

| Warning: 08 is not a legal ECMA-262 octal constant

PointedEars