Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #9249 > unrolled thread

setDate()

Back to article view | Back to comp.lang.javascript

Contents

  setDate() Gene Wirchenko <genew@ocis.net> - 2011-12-14 16:00 -0800
    Re: setDate() Jake Jarvis <pig_in_shoes@yahoo.com> - 2011-12-15 01:09 +0100
      Re: setDate() Gene Wirchenko <genew@ocis.net> - 2011-12-14 18:37 -0800
        Re: setDate() "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-12-15 12:23 +0000
          Re: setDate() Gene Wirchenko <genew@ocis.net> - 2011-12-15 12:11 -0800
            Re: setDate() "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-12-15 21:27 +0000
              Re: setDate() Gene Wirchenko <genew@ocis.net> - 2011-12-15 15:26 -0800
                Re: setDate() Swifty <steve.j.swift@gmail.com> - 2011-12-16 06:29 +0000
                Re: setDate() "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-12-16 08:41 +0000
    Re: setDate() Jake Jarvis <pig_in_shoes@yahoo.com> - 2011-12-15 12:28 +0100
      Re: setDate() Gene Wirchenko <genew@ocis.net> - 2011-12-15 12:12 -0800
        Re: setDate() "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-12-15 21:39 +0000
          Re: setDate() Jake Jarvis <pig_in_shoes@yahoo.com> - 2011-12-15 23:25 +0100
            Re: setDate() Jake Jarvis <pig_in_shoes@yahoo.com> - 2011-12-15 23:28 +0100
            Re: setDate() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-12-17 00:04 +0100
              Re: setDate() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-12-17 00:06 +0100
          Re: setDate() Swifty <steve.j.swift@gmail.com> - 2011-12-16 06:35 +0000
            Re: setDate() "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-12-16 08:29 +0000
    Re: setDate() Dr J R Stockton <reply1150@merlyn.demon.co.uk> - 2011-12-16 22:17 +0000

#9249 — setDate()

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

[toc] | [next] | [standalone]

#9251

On 15.12.2011 01:00, Gene Wirchenko wrote:
> 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.
<snip>

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

-- 
Jake Jarvis

[toc] | [prev] | [next] | [standalone]

#9255

On Thu, 15 Dec 2011 01:09:28 +0100, Jake Jarvis
<pig_in_shoes@yahoo.com> wrote:

>On 15.12.2011 01:00, Gene Wirchenko wrote:
>> 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.
><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

[toc] | [prev] | [next] | [standalone]

#9266

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?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#9274

On 15 Dec 2011 12:23:45 GMT, "Evertjan."
<exjxw.hannivoort@interxnl.net> wrote:

>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?

     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

[toc] | [prev] | [next] | [standalone]

#9279

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

> On 15 Dec 2011 12:23:45 GMT, "Evertjan."
> <exjxw.hannivoort@interxnl.net> wrote:
> 
>>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?
> 
>      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.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#9286

On 15 Dec 2011 21:27:51 GMT, "Evertjan."
<exjxw.hannivoort@interxnl.net> wrote:

[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

[toc] | [prev] | [next] | [standalone]

#9310

On Thu, 15 Dec 2011 15:26:08 -0800, Gene Wirchenko <genew@ocis.net>
wrote:

>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.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[toc] | [prev] | [next] | [standalone]

#9315

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

> On 15 Dec 2011 21:27:51 GMT, "Evertjan."
> <exjxw.hannivoort@interxnl.net> wrote:
> 
> [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.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#9264

On 15.12.2011 01:00, wrote 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().
> 

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

-- 
Jake Jarvis

[toc] | [prev] | [next] | [standalone]

#9275

On Thu, 15 Dec 2011 12:28:16 +0100, Jake Jarvis
<pig_in_shoes@yahoo.com> wrote:

>On 15.12.2011 01:00, wrote 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().

>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

[toc] | [prev] | [next] | [standalone]

#9281

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.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#9282

On 15.12.2011 22:39, Evertjan. wrote:
> 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*?

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

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

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

-- 
Jake Jarvis

[toc] | [prev] | [next] | [standalone]

#9283

On 15.12.2011 23:25, Jake Jarvis wrote:
> On 15.12.2011 22:39, Evertjan. wrote:
>> 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*?
>
> What *does* ECMA say about date objects and rolling over/under/around?
>
> I am curious, can it be decided whether the pertinent "helper
> procedures" in the specification are correct and do handle the rolling?
>
> (I'd lean towards yes, it can be decided, but I don't "see" it)
>

Firstly notwithstanding accidental bugs or deliberate deviations in 
implementations.

-- 
Jake Jarvis

[toc] | [prev] | [next] | [standalone]

#9324

Jake Jarvis wrote:

> On 15.12.2011 22:39, Evertjan. wrote:
>> 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
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#9325

Thomas 'PointedEars' Lahn wrote:

> Jake Jarvis wrote:
>> (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.

_than_  (false friends)

-- 
PointedEars

[toc] | [prev] | [next] | [standalone]

#9311

On 15 Dec 2011 21:39:26 GMT, "Evertjan."
<exjxw.hannivoort@interxnl.net> wrote:

>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.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[toc] | [prev] | [next] | [standalone]

#9313

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

> On 15 Dec 2011 21:39:26 GMT, "Evertjan."
> <exjxw.hannivoort@interxnl.net> wrote:
> 
>>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.

It seems you saw the [trafic]light.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#9328

In comp.lang.javascript message <etdie7d0tt50b7kbo00l0ojfgfggqhj9ui@4ax.
com>, Wed, 14 Dec 2011 16:00:12, Gene Wirchenko <genew@ocis.net> posted:

>     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.

-- 
 (c) John Stockton, Surrey, UK.  ?@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web