getday() doesn't agree with system clock

Discussion in 'Javascript' started by Swifty, Nov 21, 2011.

  1. Swifty

    Swifty Guest

    Source page:

    At the bottom of the page, is:

    var day = weekday();
    setInterval('getCurrentTime()', 1000);

    Which uses:

    function weekday() {
    var date = new Date();
    var dd = date.getDay();
    return dd;

    getCurrentTime does this (amongst other things)

    function getCurrentTime()
    var newday = weekday();
    if (newday !== day) window.location.reload();

    The idea is to reload the page shortly after midnight. Last night, it
    reloaded at 23:59:55 ...
    I know this, because the page is created by a CGI script which writes
    out the time that the page loaded, as part of the page.

    I've checked that the API in the scripting language is accurate; it
    matches the system clock to within 300mS at the very least (judged by
    eye, comparing my code against the time in the Windows start bar.

    So, how come the Javascript "jumped the gun" by at least 5 seconds in
    determining the Day?

    Presumably, Javascript is implemented differently in different
    browsers; should I take this up with the authors of the browser that I
    was using? (Opera; latest public release)
    Swifty, Nov 21, 2011
    1. Advertisements

  2. Time synch errors between the server and the client?


    Denis McMahon
    Denis McMahon, Nov 21, 2011
    1. Advertisements

  3. Swifty

    Elegie Guest

    On 21/11/2011 07:19, Swifty wrote :


    I can think of three possible explanations to this, and maybe there are
    more. From the most probable to the least probable:

    1) How do you know for sure that the client clock is synchronized with
    your server clock? It could very well be in advance of 5 seconds, or
    more. The small difference does indicate that both the client and the
    server regularly adjust their internal clock to match the correct time;
    but they may do so at different times of the day, or using different
    resources, resulting in a possible gap at a certain moment (the
    difference between accumulated delays of the two machines). AIUI, your
    CGI logging process uses the server time, not the client time. Maybe you
    could change your script to also pass and log the client time as
    parameter of the reload (?client-time=20111122000000)?

    2) How do you know for sure that the loaded page was a reload? Unless
    your page is private, then maybe some user or robot requested the URL
    right before midnight, and your log does not indicate it. To track this,
    you could change your script to log the IP address, and maybe a flag
    indicating whether the page was a reload (?reload=true).

    3) Neutrinos appear quite impetuous these days, and tend to go faster
    than light. As some philosopher has expressed it in the past, maybe the
    rules of the world are not fixed, and that you have witnessed first hand
    a brutal change of them - especially since you're using OPERA :)

    Kind regards,
    Elegie, Nov 21, 2011
  4. Your logic is flawed. The client-side system clock (which Date uses) and
    the server-side system clock (which the CGI script uses) do not need to
    match. If the client-side clock was ahead of the server-side clock only
    as much as 5 seconds, that would already account for your observations.
    I have no idea what that could possibly mean.
    The prefixed time unit "millisecond" is written `ms' in the Système
    international d’unités (SI), _not_ `mS'. There should be a (if possible,
    thin, non-breaking) space between number and unit: `300 ms'.

    That display has been observed to be off the system clock as well,
    particularly with DST switching. It would be best to compare against the
    clock in the configuration window that appears when you select the
    corresponding menu item in the time display's context menu, or (better)
    against the output of a COMMAND/CMD shell script repeatedly printing the
    system time.
    Most certainly it did not.
    As I have said often before (but what still does not appear to get through
    to some people): *There* *is* *no* (single) *"Javascript"* programming

    Your presumption is correct only insofar that different runtime environments
    do indeed use different *ECMAScript* implementations. One of those
    ECMAScript implementations, found in Mozilla-based browsers like Firefox, is
    _JavaScript_. Others include Microsoft JScript in MSHTML-based browsers
    like IE, Google V8 in Chromium-based browsers, Apple JavaScriptCore in
    Safari and Mobile Safari-based browsers (like the Android browser and its
    derivatives, e. g. Dolphin Browser), Opera ECMAScript in Opera browsers, and
    KJS in Konqueror:


    However, at least the mentioned ECMAScript implementations do not appear to
    vary in their implementation of the ECMAScript Date object or its getDay()
    prototype method in a way that either could be 5 seconds (or more) off the
    clock of the operating system they are used with. (CMIIW)
    No, you should first synchronize the client-side and server-side clock, or
    (easier) account for the difference between them by generating client-side
    script code to reflect the server-side value and doing the proper client-
    side computation.

    Not with javascript. Nonsense propagates like wildfire in this field.
    -- Richard Cornford, comp.lang.javascript, 2011-11-14
    Thomas 'PointedEars' Lahn, Nov 21, 2011
  5. Swifty

    SAM Guest

    Le 21/11/11 07:19, Swifty a écrit :
    not too bad if the difference between the 2 clocks (home computer and
    distant server) is only 5 or 10 seconds, no ?
    SAM, Nov 21, 2011
  6. I have confused the use of the U+2009 THIN SPACE character. It is _not_ to
    be written between number and unit, but "for numbers with many digits the
    digits may be divided into groups of three by a thin space, in order to
    facilitate reading. Neither dots nor commas are inserted in the spaces
    between groups of three." [1]

    However, it appears to be prudent to use the U+00A0 NO-BREAK SPACE character
    to separate the number and its unit, if possible. (The U+202F NARROW NO-
    BREAK SPACE character is too narrow to show the multiplication that the
    U+0020 SPACE character is supposed to convey there.)

    [1] The International System of Units (SI) (8 ed.). International Bureau of
    Weights and Measures (BIPM). 2006. pp. 134–135. Available at
    <> [online].
    Retrieved on 2011-11-21.
    Thomas 'PointedEars' Lahn, Nov 21, 2011
  7. Swifty

    Swifty Guest

    This is almost certainly the culprit, and I would never have spotted
    it, Thank you.

    The webpage in question had been hosted on my home PC until recently,
    so all of the development was done with the client and the server on
    the same system. I haven't got this concept out of my mind.

    Now I have to work out how to avoid this in future.

    That was interesting (well, I thought so). The CGI script (running on
    the remote server) calculates how many seconds there are until
    midnight. If it was less than 5, it waited until midnight before
    loading the page.

    So, I increased the margin to 10 seconds. There's probably a more
    rigorous way of doing this, but this will do for now. It's hardly the
    most important project.
    Swifty, Nov 21, 2011
  8. Swifty

    Scott Sauyet Guest

    And precisely why did you list this one as the least probable? :)

    -- Scott
    Scott Sauyet, Nov 21, 2011
  9. Swifty

    Elegie Guest

    On 21/11/2011 14:25, Scott Sauyet wrote :

    Hi Scott,
    Because it is /relatively/ improbable :)

    Elegie, Nov 21, 2011
  10. In comp.lang.javascript message <thqjc7tjcififr5ms9bbrs7v46ivmopfj6@4ax.
    You could save the client's CPU time by initially determining the
    duration in milliseconds (not milliSiemens) until midnight and then
    waiting almost all of that time in a single move. Remember that here,
    days are 23 or 24 or 25 hours, give, take, or not, one second. Remember
    that, for those with portables, "here" need not be constant.

    The milliseconds-from-epoch of next midnight is +new Date(Y, M', D, 24)
    except perhaps sometimes in the Azores, where Y M D is today ; it is
    that which should be used to determine when to wait for.
    Dr J R Stockton, Nov 22, 2011
  11. Swifty

    Swifty Guest

    Indeed, and that is something that I customarily do in other
    situations like this.

    But the:

    setInterval('getCurrentTime()', 1000);

    .... has another purpose. It updates the time at the top right of the
    page. I didn't mention this in earlier posts, as it wasn't germane.

    The whole purpose of the webpage is the passage of time, from seconds
    to years (or decades in the case of some versions of my page run for
    other people).
    Swifty, Nov 23, 2011
  12. Well if that is the case, do you need to show the server
    time? Maybe you can show the local time instead and still
    reload the page? Using, of course, the same reload function?

    Or is there some other important info coming in with the page
    Zlatko Äurić, Nov 23, 2011
  13. Swifty

    Swifty Guest

    About the most important aspect of that is that it enabled me to see
    that the page was loading just BEFORE midnight (at the server) and
    that explained why I sometimes had the wrong number of tally marks on
    the page.

    I probably should take the page reload information out, now that it's
    done it's job of allowing the helpful people here to solve my problem
    for me. But somehow I've become attached to it. :)
    Swifty, Nov 24, 2011
    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.