getTime, setTime, recent change in daylight savings

Discussion in 'Javascript' started by Zamdrist, Apr 6, 2009.

  1. Zamdrist

    Zamdrist Guest

    I'm looking at an application written by a third party, its not my
    code. While I'm a programmer type, I'm not terribly versed in the
    details of Javacript.

    Our problems lies in that during the recent daylight savings change,
    we've had a user, who resides in the Mountain timezone. The software,
    a web application was showing a timer with the the wrong start time,
    one hour wrong. Both the server and his machine said the correct time,
    that is Windows said the correct time.

    I think I've tracked down the code from the application that
    determines the time. Can someone tell me if this code is correct, and
    if its possible determine if it could be the culprit?

    var date = new Date();
    date.setTime(date.getTime() + 3650*24*60*60*1000);

    I know that getTime returns the number of milliseconds from 1/1/1970,
    so supposedly the addition of (3650*24*60*60*1000) brings the value of
    getTime to a current time...?

    Ideas? Thanks
     
    Zamdrist, Apr 6, 2009
    #1
    1. Advertising

  2. Zamdrist

    Thomas Allen Guest

    On Apr 6, 2:47 pm, Zamdrist <> wrote:
    > I'm looking at an application written by a third party, its not my
    > code. While I'm a programmer type, I'm not terribly versed in the
    > details of Javacript.
    >
    > Our  problems lies in that during the recent daylight savings change,
    > we've had a user, who resides in the Mountain timezone. The software,
    > a web application was showing a timer with the the wrong start time,
    > one hour wrong. Both the server and his machine said the correct time,
    > that is Windows said the correct time.
    >
    > I think I've tracked down the code from the application that
    > determines the time. Can someone tell me if this code is correct, and
    > if its possible determine if it could be the culprit?
    >
    > var date = new Date();
    > date.setTime(date.getTime() + 3650*24*60*60*1000);
    >
    > I know that getTime returns the number of milliseconds from 1/1/1970,
    > so supposedly the addition of (3650*24*60*60*1000) brings the value of
    > getTime to a current time...?
    >
    > Ideas? Thanks


    Well, the added milliseconds part is about ten years (3650 * ms in a
    day). I have no idea why that code would be there. A new Date object
    is current by default, so no need to "bring it up to date" as you
    mentioned.

    Thomas
     
    Thomas Allen, Apr 6, 2009
    #2
    1. Advertising

  3. Zamdrist

    Zamdrist Guest

    On Apr 6, 1:58 pm, Thomas Allen <> wrote:
    > On Apr 6, 2:47 pm, Zamdrist <> wrote:
    >
    >
    >
    > > I'm looking at an application written by a third party, its not my
    > > code. While I'm a programmer type, I'm not terribly versed in the
    > > details of Javacript.

    >
    > > Our  problems lies in that during the recent daylight savings change,
    > > we've had a user, who resides in the Mountain timezone. The software,
    > > a web application was showing a timer with the the wrong start time,
    > > one hour wrong. Both the server and his machine said the correct time,
    > > that is Windows said the correct time.

    >
    > > I think I've tracked down the code from the application that
    > > determines the time. Can someone tell me if this code is correct, and
    > > if its possible determine if it could be the culprit?

    >
    > > var date = new Date();
    > > date.setTime(date.getTime() + 3650*24*60*60*1000);

    >
    > > I know that getTime returns the number of milliseconds from 1/1/1970,
    > > so supposedly the addition of (3650*24*60*60*1000) brings the value of
    > > getTime to a current time...?

    >
    > > Ideas? Thanks

    >
    > Well, the added milliseconds part is about ten years (3650 * ms in a
    > day). I have no idea why that code would be there. A new Date object
    > is current by default, so no need to "bring it up to date" as you
    > mentioned.
    >
    > Thomas


    What's interesting, using Firefox's javacript code window I added
    window.alert(date);

    And sure enough its one hour off (early). It also says GMT -0600 (CST)

    Is it just expressing that the current time CST is 6 hours prior to
    GMT?
     
    Zamdrist, Apr 6, 2009
    #3
  4. Zamdrist

    Zamdrist Guest

    I think because the code runs server side (CST) the calculation is
    there to account for the user being in a different time zone? Its the
    only think that makes sense to me.
     
    Zamdrist, Apr 6, 2009
    #4
  5. Zamdrist

    Thomas Allen Guest

    On Apr 6, 3:47 pm, Zamdrist <> wrote:
    > I think because the code runs server side (CST) the calculation is
    > there to account for the user being in a different time zone? Its the
    > only think that makes sense to me.


    Date checks the local time, not a server. I don't know enough about
    the implementation to speculate as to why the time zones may not
    match, and I've never experienced this problem before. It sounds like
    something OS-level.

    Thomas
     
    Thomas Allen, Apr 6, 2009
    #5
  6. Zamdrist

    Evertjan. Guest

    Thomas Allen wrote on 06 apr 2009 in comp.lang.javascript:

    > On Apr 6, 3:47ÿpm, Zamdrist <> wrote:
    >> I think because the code runs server side (CST) the calculation is
    >> there to account for the user being in a different time zone? Its the
    >> only think that makes sense to me.

    >
    > Date checks the local time, not a server.


    It can be server local or client local
    depending on where the Javascript executes.

    =======================================
    Server time was:
    <%
    response.write(new Date());
    %>

    <br>
    and client time was:

    <script type='text/javascript'>
    document.write(new Date());
    </script>

    <br>
    when this pege was loaded.
    =======================================

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Apr 6, 2009
    #6
  7. Zamdrist

    Zamdrist Guest

    On Apr 6, 3:00 pm, "Evertjan." <> wrote:
    > Thomas Allen wrote on 06 apr 2009 in comp.lang.javascript:
    >
    > > On Apr 6, 3:47ÿpm, Zamdrist <> wrote:
    > >> I think because the code runs server side (CST) the calculation is
    > >> there to account for the user being in a different time zone? Its the
    > >> only think that makes sense to me.

    >
    > > Date checks the local time, not a server.

    >
    > It can be server local or client local
    > depending on where the Javascript executes.
    >
    > =======================================
    > Server time was:
    > <%
    > response.write(new Date());
    > %>
    >
    > <br>
    > and client time was:
    >
    > <script type='text/javascript'>
    > document.write(new Date());
    > </script>
    >
    > <br>
    > when this pege was loaded.
    > =======================================
    >
    > --
    > Evertjan.
    > The Netherlands.
    > (Please change the x'es to dots in my emailaddress)


    That's what I figured, all depends on where the code executes. And so
    far as I can tell, it executes on the server.

    If its an OS-level issue with the client or server, I don't know how
    when the times on both the server and client have always shown the
    correct time. Its only the web application, and I'm presuming the code
    I posted that calculates the wrong time.

    Try it:

    var date = new Date();
    date.setTime(date.getTime() + 3650*24*60*60*1000);
    window.alert(date);
     
    Zamdrist, Apr 6, 2009
    #7
  8. Zamdrist

    Thomas Allen Guest

    On Apr 6, 4:18 pm, Zamdrist <> wrote:
    > On Apr 6, 3:00 pm, "Evertjan." <> wrote:
    >
    >
    >
    > > Thomas Allen wrote on 06 apr 2009 in comp.lang.javascript:

    >
    > > > On Apr 6, 3:47ÿpm, Zamdrist <> wrote:
    > > >> I think because the code runs server side (CST) the calculation is
    > > >> there to account for the user being in a different time zone? Its the
    > > >> only think that makes sense to me.

    >
    > > > Date checks the local time, not a server.

    >
    > > It can be server local or client local
    > > depending on where the Javascript executes.

    >
    > > =======================================
    > > Server time was:
    > > <%
    > > response.write(new Date());
    > > %>

    >
    > > <br>
    > > and client time was:

    >
    > > <script type='text/javascript'>
    > > document.write(new Date());
    > > </script>

    >
    > > <br>
    > > when this pege was loaded.
    > > =======================================

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

    >
    > That's what I figured, all depends on where the code executes. And so
    > far as I can tell, it executes on the server.
    >
    > If its an OS-level issue with the client or server, I don't know how
    > when the times on both the server and client have always shown the
    > correct time. Its only the web application, and I'm presuming the code
    > I posted that calculates the wrong time.
    >
    > Try it:
    >
    > var date = new Date();
    > date.setTime(date.getTime() + 3650*24*60*60*1000);
    > window.alert(date);


    What you have there posts the wrong time, about ten years ahead.
    Hours:Minutes:Seconds are correct however.

    Thomas
     
    Thomas Allen, Apr 6, 2009
    #8
  9. Zamdrist

    Zamdrist Guest

    On Apr 6, 3:22 pm, Thomas Allen <> wrote:
    > On Apr 6, 4:18 pm, Zamdrist <> wrote:
    >
    >
    >
    > > On Apr 6, 3:00 pm, "Evertjan." <> wrote:

    >
    > > > Thomas Allen wrote on 06 apr 2009 in comp.lang.javascript:

    >
    > > > > On Apr 6, 3:47ÿpm, Zamdrist <> wrote:
    > > > >> I think because the code runs server side (CST) the calculation is
    > > > >> there to account for the user being in a different time zone? Its the
    > > > >> only think that makes sense to me.

    >
    > > > > Date checks the local time, not a server.

    >
    > > > It can be server local or client local
    > > > depending on where the Javascript executes.

    >
    > > > =======================================
    > > > Server time was:
    > > > <%
    > > > response.write(new Date());
    > > > %>

    >
    > > > <br>
    > > > and client time was:

    >
    > > > <script type='text/javascript'>
    > > > document.write(new Date());
    > > > </script>

    >
    > > > <br>
    > > > when this pege was loaded.
    > > > =======================================

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

    >
    > > That's what I figured, all depends on where the code executes. And so
    > > far as I can tell, it executes on the server.

    >
    > > If its an OS-level issue with the client or server, I don't know how
    > > when the times on both the server and client have always shown the
    > > correct time. Its only the web application, and I'm presuming the code
    > > I posted that calculates the wrong time.

    >
    > > Try it:

    >
    > > var date = new Date();
    > > date.setTime(date.getTime() + 3650*24*60*60*1000);
    > > window.alert(date);

    >
    > What you have there posts the wrong time, about ten years ahead.
    > Hours:Minutes:Seconds are correct however.
    >
    > Thomas


    Yeah, its goofy. Like I said, I didn't write it. Someone who makes a
    rude amount of money more than I do, did.
     
    Zamdrist, Apr 6, 2009
    #9
  10. Zamdrist

    RobG Guest

    On Apr 7, 5:04 am, Zamdrist <> wrote:
    > On Apr 6, 1:58 pm, Thomas Allen <> wrote:
    >
    >
    >
    > > On Apr 6, 2:47 pm, Zamdrist <> wrote:

    >
    > > > I'm looking at an application written by a third party, its not my
    > > > code. While I'm a programmer type, I'm not terribly versed in the
    > > > details of Javacript.

    >
    > > > Our problems lies in that during the recent daylight savings change,
    > > > we've had a user, who resides in the Mountain timezone. The software,
    > > > a web application was showing a timer with the the wrong start time,
    > > > one hour wrong. Both the server and his machine said the correct time,
    > > > that is Windows said the correct time.

    >
    > > > I think I've tracked down the code from the application that
    > > > determines the time. Can someone tell me if this code is correct, and
    > > > if its possible determine if it could be the culprit?

    >
    > > > var date = new Date();
    > > > date.setTime(date.getTime() + 3650*24*60*60*1000);


    That is very strange code. It adds about 10 years to the date object
    created by new Date, but does not account for for leap years. Since
    it is roughly (not exactly) a whole number of years, daylight saving
    will affect the calculation for a few days per year.

    If you want to find out how many seconds there are between now and
    some date in the future, use the setYear, setMonth and setDate methods
    of a date object, then subtract the two times, e.g.

    var now = new Date();
    var tenYearsHence = new Date(+now);
    tenYearsHence.setYear(now.getFullYear() + 10);

    alert(
    'Now: ' + now
    + '\nTen years hence: ' + tenYearsHence
    + '\nSeconds between: ' + (tenYearsHence - now)/1000
    );


    Of course using local calculations for dates is always problemtatic as
    you don't know whether the system's clock is correctly set or that the
    user knows what it is (it may not be their system, nor might they have
    control over the date and time settings).


    > > > I know that getTime returns the number of milliseconds from 1/1/1970,
    > > > so supposedly the addition of (3650*24*60*60*1000) brings the value of
    > > > getTime to a current time...?


    No. It gives a date about 1 to 3 days short of 10 years in the
    future. Depending on when the date is calculated, there might be one,
    two or three leap years in between that aren't accounted for and it
    might therefore also not account for a daylight saving time change, so
    it might be out by an hour one way or the other occassionally.


    > > > Ideas? Thanks

    >
    > > Well, the added milliseconds part is about ten years (3650 * ms in a
    > > day). I have no idea why that code would be there. A new Date object
    > > is current by default, so no need to "bring it up to date" as you
    > > mentioned.


    It is current for the system settings, which may not be correct.


    > What's interesting, using Firefox's javacript code window I added
    > window.alert(date);


    Presumably you did:

    alert(new Date());

    > And sure enough its one hour off (early).


    That means you have a setting somwhere that is inconsistent with what
    you think the local time is.


    > It also says GMT -0600 (CST)
    >
    > Is it just expressing that the current time CST is 6 hours prior to
    > GMT?


    The opposite: the time is 6 hours behind UTC (GMT is more or less
    deprecated, although still commonly used).

    <URL: http://en.wikipedia.org/wiki/GMT >

    You can use date.getTimezoneOffset() to see the offset in minutes (for
    UTC -0600 it should say 360, my timezone is UTC +1000 so I get -600).
    The timezone offset is added to the local time to get UTC.

    When dealing with time, it is best to do everything in UTC and convert
    to local time only for the sake of display. It may also be prudent to
    display the result of new Date() so the user can check if it is
    correct (and hence infer whether calculations based on it are likely
    to be correct).


    --
    Rob
     
    RobG, Apr 7, 2009
    #10
  11. Zamdrist

    Evertjan. Guest

    Zamdrist wrote on 06 apr 2009 in comp.lang.javascript:

    >> ========================

    > ==============> Server time was:
    >> <%
    >> response.write(new Date());
    >> %>
    >>
    >> <br>
    >> and client time was:
    >>
    >> <script type='text/javascript'>
    >> document.write(new Date());
    >> </script>
    >>
    >> <br>
    >> when this pege was loaded.
    >> ========================

    > ==============>


    [please do not quote signatures on usenet]

    >
    > That's what I figured, all depends on where the code executes. And so
    > far as I can tell, it executes on the server.


    How can you not be sure, when you are writing the code?

    > If its an OS-level issue with the client or server, I don't know how
    > when the times on both the server and client have always shown the
    > correct time. Its only the web application, and I'm presuming the code
    > I posted that calculates the wrong time.
    >
    > Try it:
    >
    > var date = new Date();
    > date.setTime(date.getTime() + 3650*24*60*60*1000);


    Do you know what clients locale summertime [dst] laws will be in 10 years
    time?

    > window.alert(date);
    >


    This is not possible on the server: window.alert()
    [and if there were a window on the server,
    you would not see it on the client.]




    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Apr 7, 2009
    #11
  12. In comp.lang.javascript message <dac07a05-93de-4fa6-8424-fd7f3a33c26e@e5
    g2000vbe.googlegroups.com>, Mon, 6 Apr 2009 11:47:49, Zamdrist
    <> posted:

    >Our problems lies in that during the recent daylight savings change,
    >we've had a user, who resides in the Mountain timezone.


    Many people live in places with mountains. This is an international
    newsgroup, and it is foolish to expect readers world-wide to be familiar
    with every state's local arrangements. To be courteous, be explicit
    and accurate.

    Given that there has been a clock change, the location is irrelevant,
    provided that one can assume it is not Lord Howe Island - which, for its
    size, is actually modestly mountainous, and has a time zone shared only
    with unpopulated(?) neighbours.


    > The software,
    >a web application was showing a timer with the the wrong start time,
    >one hour wrong. Both the server and his machine said the correct time,
    >that is Windows said the correct time.
    >
    >I think I've tracked down the code from the application that
    >determines the time. Can someone tell me if this code is correct, and
    >if its possible determine if it could be the culprit?
    >
    >var date = new Date();
    >date.setTime(date.getTime() + 3650*24*60*60*1000);


    One cannot tell whether such a code fragment is correct without knowing
    what it needs to do. The "designer" might have specified, wisely or
    foolishly but authoritatively, that the time should be moved ahead by 10
    years of 365 days of 24 hours, in which case the code is satisfactory
    though a numerate coder would know that a day usually has 86400 seconds
    and avoid writing unnecessary multiplications. One should know that
    there are 864e5 ms/day.


    >I know that getTime returns the number of milliseconds from 1/1/1970,


    From 1970-01-01 00:00:00 UTC.


    >so supposedly the addition of (3650*24*60*60*1000) brings the value of
    >getTime to a current time...?


    It is adding ten years worth of absolute time, on the assumption that
    Leap Years have been abolished and the state of Summer Time will be the
    same at the end as at the beginning.

    A likely intent is to get a date/time about ten years from now, and for
    that one should use
    var date = new Date(); // then one of
    1. date.setYear(date.getYear()+10)
    2. date.setFullYear(date.getFullYear()+10)
    3. date.setUTCFullYear(date.getUTCFullYear()+10) // faster

    There, 1 is slovenly but probably safe; 2 will move ahead exactly 10
    civil years, if possible (there is a missing hour each Spring, in many
    places; 3 is faster but may appear an hour in error if an odd number of
    Summer Time changed are crossed. Your code is equivalent to 3, apart
    from having the year-length error.

    To fix the problem, you will need to understand the needs and intent of
    the time-handling of the system; looking at a fragment is insufficient.

    --
    (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
    Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
    PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
    Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
     
    Dr J R Stockton, Apr 7, 2009
    #12
  13. In comp.lang.javascript message <14741c42-d7e8-4370-95d5-b48f2cbea3d0@y3
    3g2000prg.googlegroups.com>, Mon, 6 Apr 2009 16:40:59, RobG
    <> posted:
    >On Apr 7, 5:04 am, Zamdrist <> wrote:


    >> > On Apr 6, 2:47 pm, Zamdrist <> wrote:
    >> > > var date = new Date();
    >> > > date.setTime(date.getTime() + 3650*24*60*60*1000);

    >
    >That is very strange code. It adds about 10 years to the date object
    >created by new Date, but does not account for for leap years. Since
    >it is roughly (not exactly) a whole number of years, daylight saving
    >will affect the calculation for a few days per year.


    The ordinal and calendar dates of Summer Time vary more or less
    systematically from year to year. Therefore, Summer Time would still be
    able to have an effect, occasionally, even if the step were an exact
    number of calendar years. In most places using Summer Time, stepping a
    multiple of 28 years (except across a missing leap year), or a multiple
    of 400 years, would be safe.


    >If you want to find out how many seconds there are between now and
    >some date in the future, use the setYear, setMonth and setDate methods


    Better to use setFullYear. Firstly, setYear ... getFullYear looks wring
    (though it's OK); secondly, getFullYear can be given all three
    arguments. In fact, one should not set year, month, and date
    individually unless the initial date is known to be, or is changed to,
    less than 29. Consider 2009-01-31 ; set year 2010, 2010-01-31, OK; set
    Month 1 (Feb), 2010-03-03 OOOH!; set Date 22, 2010-03-22. BUT
    2009-01-31, set Full Year 2010 1 22, 2010-02-22.



    >> > > I know that getTime returns the number of milliseconds from 1/1/1970,
    >> > > so supposedly the addition of (3650*24*60*60*1000) brings the value of
    >> > > getTime to a current time...?

    >
    >No. It gives a date about 1 to 3 days short of 10 years in the
    >future. Depending on when the date is calculated, there might be one,
    >two or three leap years in between that aren't accounted for and it
    >might therefore also not account for a daylight saving time change, so
    >it might be out by an hour one way or the other occassionally.


    Given that new Date() is used, the chances of there being only one leap
    year in a ten-year span within the lifetime of the code - or its author
    - are probably negligible.


    If the intention is like to set a cookie date ten years ahead, so that
    in practice it will not expire, it would be smarter just to set a fixed
    literal date such as 9999-12-25.

    --
    (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
    Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
    PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
    Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
     
    Dr J R Stockton, Apr 7, 2009
    #13
  14. Zamdrist

    Zamdrist Guest

    Had I known I'd be flogged in such a manner, I'd rather not have
    bothered.

    Duly noted.
     
    Zamdrist, Apr 9, 2009
    #14
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ryan Ternier
    Replies:
    1
    Views:
    1,471
    Ryan Ternier
    Oct 14, 2005
  2. Svante Nicholas Arvedahl

    Daylight savings problem

    Svante Nicholas Arvedahl, Oct 20, 2003, in forum: Java
    Replies:
    9
    Views:
    4,973
    Svante Nicholas Arvedahl
    Oct 24, 2003
  3. Hariharan.A
    Replies:
    0
    Views:
    1,732
    Hariharan.A
    Feb 25, 2004
  4. lordy
    Replies:
    3
    Views:
    1,919
    lordy
    Jul 14, 2006
  5. js
    Replies:
    1
    Views:
    791
Loading...

Share This Page