setDate()

[Gene Wirchenko]

Dear JavaScripters:

I have just about finished my date class. One of the last
consequential functions is to add/subtract days from a date.

In IE9, with Date, one can do
SomeDate.setDate(SomeDate.getDate()+n);
and if there is overflow in the days of the month, the date will be
normalised. e.g. 2011-12-31 + 32 = 2012-02-01.

Is this behaviour that I can count on? It seems to fail at 366
days. I have seen nothing documenting the normalising, but the
standard says very little about Date's setDate().

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

<snip>

What do you mean with "fail at 366 days"?

Never mind. I goofed again. I was calling the wrong routine on
the last few cases.

I still would like to know if I can count on
SomeDate.setDate(SomeDate.getDate()+n);
being normalised when the resulting day of month is out of range. I
could write the code myself to do this, but if I really do not have
to, so much the better.

Sincerely,

Gene Wirchenko

 

[Evertjan.]

Gene Wirchenko wrote on 15 dec 2011 in comp.lang.javascript:

I still would like to know if I can count on
SomeDate.setDate(SomeDate.getDate()+n);
being normalised when the resulting day of month is out of range. I
could write the code myself to do this, but if I really do not have
to, so much the better.

This is something you can easily test yourself.
Why should we test it for you?

 

[Gene Wirchenko]

Gene Wirchenko wrote on 15 dec 2011 in comp.lang.javascript:

This is something you can easily test yourself.
Why should we test it for you?

I am not asking you to test it for me. I am asking if I can
count on the behaviour that I have already established by testing.

It might be that I can count on the behaviour. If so, where is
this documented? If not, then I would rather not have my code break
in the future on a different browser.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

What do you mean when you say "the standard"?

JavaScript's standard:

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
Did I get the right one?

Sincerely,

Gene Wirchenko

 

[Evertjan.]

Gene Wirchenko wrote on 15 dec 2011 in comp.lang.javascript:

I am not asking you to test it for me. I am asking if I can
count on the behaviour that I have already established by testing.

Which I can only answer with the results of my testing,
either in the past or in the future.

[btw: Since I often use this method, my tests make me trust the method to
be sound on the browser js-engines I tested, but not on say Iphone, since i
am a Chrome and Android person with limited resources.]

It might be that I can count on the behaviour. If so, where is
this documented? If not, then I would rather not have my code break
in the future on a different browser.

Gene, that is not the way the javascript universe works.

If you want to be sure of the effect, you test it,
never trust the specs to be final.

The specs only tell you how it was ment to work.

So in fact you were [unknowingly perhaps] asking me to test it for you.

 

[Evertjan.]

Gene Wirchenko wrote on 15 dec 2011 in comp.lang.javascript:

[...]
JavaScript's standard:

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
Did I get the right one?

This is like saying you cannot get killed having green at the traffic
lights, BECAUSE the law says other lights must have red.

No, ECMA defines how a javascript engine should work in their eyes,
no javascript engine works exactly that way, because the builders of the
engines either think of an in their eyse better way, or because they made
stupid mistakes.

So you cannot count on what ECMA says.

You should test it.

 

[Gene Wirchenko]

On 15 Dec 2011 21:27:51 GMT, "Evertjan."

[snip]

Gene, that is not the way the javascript universe works.

If you want to be sure of the effect, you test it,
never trust the specs to be final.

Of course I test it, but I want to know if I should even be doing
it that way.

The specs only tell you how it was ment to work.

So in fact you were [unknowingly perhaps] asking me to test it for you.

No, I am asking if it is meant to work that way. I can handle my
own testing.

Sincerely,

Gene Wirchenko

 

[Swifty]

No, I am asking if it is meant to work that way. I can handle my
own testing.

Back in the Physics department in 1984, holy wars would break out
between the theoretical physicists and the experimental physicists.

Nothing changes.

What we need here is a theoretical javascripter.

 

[Swifty]

This is like saying you cannot get killed having green at the traffic
lights, BECAUSE the law says other lights must have red.

Yes, but the person who bases their actions purely on experiment is
likely to deduce that the colours are irrelevant near where I live, as
the traffic volume is so low that the colours rarely matter.

In this case, it is better to understand the rules, and then work out
experimentally if they apply. You will discover that they apply 99.99%
of the time, but that there are exceptions, caused by idiots.

Everyone think's I'm mad because I look both ways before entering a
one-way street... experience in action.

 

[Evertjan.]

Swifty wrote on 16 dec 2011 in comp.lang.javascript:

Yes, but the person who bases their actions purely on experiment is
likely to deduce that the colours are irrelevant near where I live, as
the traffic volume is so low that the colours rarely matter.

In this case, it is better to understand the rules, and then work out
experimentally if they apply. You will discover that they apply 99.99%
of the time, but that there are exceptions, caused by idiots.

Everyone think's I'm mad because I look both ways before entering a
one-way street... experience in action.

It seems you saw the [trafic]light.

 

[Evertjan.]

Gene Wirchenko wrote on 16 dec 2011 in comp.lang.javascript:

On 15 Dec 2011 21:27:51 GMT, "Evertjan."

[snip]

Gene, that is not the way the javascript universe works.

If you want to be sure of the effect, you test it,
never trust the specs to be final.

Of course I test it, but I want to know if I should even be doing
it that way.

The specs only tell you how it was ment to work.

So in fact you were [unknowingly perhaps] asking me to test it for you.

No, I am asking if it is meant to work that way. I can handle my
own testing.

It stands to reason it was ment to work that way, imho.

However you did not ask that,
you asked if you could count on it [to work].

Good intentions of ECMA, even this month's,
are just proof of concept,
not proof of [cross-browser] executability.

 

[Dr J R Stockton]

In comp.lang.javascript message <etdie7d0tt50b7kbo00l0ojfgfggqhj9ui@4ax.

I have just about finished my date class. One of the last
consequential functions is to add/subtract days from a date.

In IE9, with Date, one can do
SomeDate.setDate(SomeDate.getDate()+n);
and if there is overflow in the days of the month, the date will be
normalised. e.g. 2011-12-31 + 32 = 2012-02-01.

Is this behaviour that I can count on? It seems to fail at 366
days. I have seen nothing documenting the normalising, but the
standard says very little about Date's setDate().

Section 15.9.5.37 of the current ECMA standard tells you exactly what
should happen. Just work through it, step by step.

I have a vague recollection of a system using 16-bit arithmetic for such
things, limiting n to -32768 .. +32767. It should be extinct.

Read <http://www.merlyn.demon.co.uk/js-datex.htm> &
<http://www.merlyn.demon.co.uk/js-flaws.htm>. They prove that very
little can be trusted, in browsers as a whole. One cannot even rely on
new Date(Y, 0, 1) == new Date(Y + "/01/01")
for more than the next 23 years.

But the only date bug I know of in IE9 (which I do not have) is in
VBScript.

But that's a bad statement - there is no JavaScript or VBscript in IE9
(if it resembles earlier IE). Instead, they use script engines shared
by the rest of MS Windows - and those may be updated at any time. So
one needs to re-test after any script engine update,

If you need to add/subtract days, and to use Y M D, the safest way of
all is to store dates as integers (signed 16-bit will serve for a
working lifetime, except for the occasional Senator) and to have
reliable routines for Y, M, D to/from integer and for local date string
(maybe BC uses FFF dates) to/from integer and for company date string
to/from integer.

In your commercial application, the range of dates you care about is not
great; there are only 146097 days in 400 years Gregorian. You can test
all possible steps for dates in your career in under a US billion goes,
which will not take too long to try.

 

[Thomas 'PointedEars' Lahn]

Gene Wirchenko wrote on 15 dec 2011 in comp.lang.javascript:

Is this behaviour that I can count on? [...]
JavaScript's standard:

http://www.ecma-international.org/publications/files/ECMA- ST/Ecma-262.pdf
Did I get the right one?

This is like saying you cannot get killed having green at the traffic
lights, BECAUSE the law says other lights must have red.

No, ECMA defines how a javascript engine should work in their eyes,
no javascript engine works exactly that way, because the builders of the
engines either think of an in their eyse better way, or because they made
stupid mistakes.

So you cannot count on what ECMA says.

You should test it.

Test *what*?

For example:

var d = new Date(2011, 11, 31, 0, 0, 0, 0);
d.setDate(d.getDate() + 1);

/* Should be 2012 */
console.log(d.getYear());

What *does* ECMA say about date objects and rolling over/under/around?

For a given combination of date components, a conforming implementation is
required to find a date that meets certain criteria. IOW, both date
underflow and overflow are built-in. BTW, this is not a peculiar of
ECMAScript at all; for example, PHP's date() function exhibits the very same
behavior (only that month numbers are 1-based there).

I am curious, can it be decided whether the pertinent "helper
procedures" in the specification are correct and do handle the rolling?
Yes.

(I'd lean towards yes, it can be decided, but I don't "see" it)

The "magic" happens in the MakeDay(year, month, date) algorithm called e. g.
in step 3 of the Date.prototype.setDate(date) algorithm of ECMAScript
Edition 5.1. It is actually much clearer specified there as I remember it
from ES 3, which is seldom the case with ES 5.x.


PointedEars

 

[Thomas 'PointedEars' Lahn]

The "magic" happens in the MakeDay(year, month, date) algorithm called e.
g. in step 3 of the Date.prototype.setDate(date) algorithm of ECMAScript
Edition 5.1. It is actually much clearer specified there as I remember it ^^
from ES 3, which is seldom the case with ES 5.x.

_than_ (false friends)