setDate()

Discussion in 'Javascript' started by Gene Wirchenko, Dec 15, 2011.

  1. 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, Dec 15, 2011
    #1
    1. Advertisements

  2. 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
     
    Gene Wirchenko, Dec 15, 2011
    #2
    1. Advertisements

  3. Gene Wirchenko

    Evertjan. Guest

    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?
     
    Evertjan., Dec 15, 2011
    #3
  4. 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, Dec 15, 2011
    #4
  5. Gene Wirchenko, Dec 15, 2011
    #5
  6. Gene Wirchenko

    Evertjan. Guest

    Gene Wirchenko wrote on 15 dec 2011 in comp.lang.javascript:
    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.]
    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., Dec 15, 2011
    #6
  7. Gene Wirchenko

    Evertjan. Guest

    Gene Wirchenko wrote on 15 dec 2011 in comp.lang.javascript:
    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., Dec 15, 2011
    #7
  8. On 15 Dec 2011 21:27:51 GMT, "Evertjan."

    [snip]
    Of course I test it, but I want to know if I should even be doing
    it that way.
    No, I am asking if it is meant to work that way. I can handle my
    own testing.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Dec 15, 2011
    #8
  9. Gene Wirchenko

    Swifty Guest

    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, Dec 16, 2011
    #9
  10. Gene Wirchenko

    Swifty Guest

    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.
     
    Swifty, Dec 16, 2011
    #10
  11. Gene Wirchenko

    Evertjan. Guest

    Swifty wrote on 16 dec 2011 in comp.lang.javascript:
    It seems you saw the [trafic]light.
     
    Evertjan., Dec 16, 2011
    #11
  12. Gene Wirchenko

    Evertjan. Guest

    Gene Wirchenko wrote on 16 dec 2011 in comp.lang.javascript:
    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., Dec 16, 2011
    #12
  13. In comp.lang.javascript message <etdie7d0tt50b7kbo00l0ojfgfggqhj9ui@4ax.
    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.
     
    Dr J R Stockton, Dec 16, 2011
    #13
  14. 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());
    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).
    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, Dec 16, 2011
    #14
  15. _than_ (false friends)
     
    Thomas 'PointedEars' Lahn, Dec 16, 2011
    #15
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.