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

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

getday() doesn't agree with system clock

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

Contents

  getday() doesn't agree with system clock Swifty <steve.j.swift@gmail.com> - 2011-11-21 06:19 +0000
    Re: getday() doesn't agree with system clock Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-21 08:49 +0000
      Re: getday() doesn't agree with system clock Swifty <steve.j.swift@gmail.com> - 2011-11-21 13:19 +0000
    Re: getday() doesn't agree with system clock Elegie <elegie@anonymous.invalid> - 2011-11-21 09:53 +0100
      Re: getday() doesn't agree with system clock Scott Sauyet <scott.sauyet@gmail.com> - 2011-11-21 05:25 -0800
        Re: getday() doesn't agree with system clock Elegie <elegie@anonymous.invalid> - 2011-11-21 19:45 +0100
    Re: getday() doesn't agree with system clock Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-21 10:20 +0100
      Re: getday() doesn't agree with system clock Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-21 11:11 +0100
    Re: getday() doesn't agree with system clock SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2011-11-21 10:43 +0100
    Re: getday() doesn't agree with system clock Dr J R Stockton <reply1147@merlyn.demon.co.uk> - 2011-11-22 20:05 +0000
      Re: getday() doesn't agree with system clock Swifty <steve.j.swift@gmail.com> - 2011-11-23 05:24 +0000
        Re: getday() doesn't agree with system clock Zlatko Đurić <zladuric@gmail.com> - 2011-11-23 22:30 +0100
          Re: getday() doesn't agree with system clock Swifty <steve.j.swift@gmail.com> - 2011-11-24 06:15 +0000

#8502 — getday() doesn't agree with system clock

Source page: http://www.swiftys.org.uk/retire

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)

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

[toc] | [next] | [standalone]

#8503

On Mon, 21 Nov 2011 06:19:22 +0000, Swifty wrote:

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

Time synch errors between the server and the client?

Rgds

Denis McMahon

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

#8509

On 21 Nov 2011 08:49:14 GMT, Denis McMahon <denismfmcmahon@gmail.com>
wrote:

>Time synch errors between the server and the client?

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.

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

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

#8504

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

Hello,

<snip>

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

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

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.

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

#8510

Elegie wrote:
> 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 :)

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

  -- Scott

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

#8515

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

Hi Scott,

>> 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 :)

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

Because it is /relatively/ improbable :)

Cheers,
Elegie.

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

#8505

Swifty wrote:

> Source page: http://www.swiftys.org.uk/retire
> 
> 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.

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've checked that the API in the scripting language is accurate;

I have no idea what that could possibly mean.

> it matches the system clock to within 300mS at the very least (judged by

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

<http://en.wikipedia.org/wiki/International_System_of_Units>

> eye, comparing my code against the time in the Windows start bar.

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.

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

Most certainly it did not.
 
> Presumably, Javascript is implemented differently in different browsers;

As I have said often before (but what still does not appear to get through 
to some people): *There* *is* *no* (single) *"Javascript"* programming 
language.  

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:

<http://PointedEars.de/es-matrix>

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)

> should I take this up with the authors of the browser that I
> was using? (Opera; latest public release)

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.


PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

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

#8507

Thomas 'PointedEars' Lahn wrote:

> Swifty wrote:
>> it matches the system clock to within 300mS at the very least (judged by
> 
> 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'.
> 
> <http://en.wikipedia.org/wiki/International_System_of_Units>

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

 
PointedEars
___________
[1] The International System of Units (SI) (8 ed.). International Bureau of
    Weights and Measures (BIPM). 2006. pp. 134–135.  Available at
    <http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf> [online]. 
    Retrieved on 2011-11-21.
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

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

#8506

Le 21/11/11 07:19, Swifty a écrit :
> Source page: http://www.swiftys.org.uk/retire
(...)
> The idea is to reload the page shortly after midnight. Last night, it
> reloaded at 23:59:55 ...

not too bad if the difference between the 2 clocks (home computer and 
distant server) is only 5 or 10 seconds, no ?

-- 
Stéphane Moriaux avec/with iMac-intel

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

#8545

In comp.lang.javascript message <thqjc7tjcififr5ms9bbrs7v46ivmopfj6@4ax.
com>, Mon, 21 Nov 2011 06:19:22, Swifty <steve.j.swift@gmail.com>
posted:

>Source page: http://www.swiftys.org.uk/retire
>
>At the bottom of the page, is:
>
>  var day = weekday();
>  setInterval('getCurrentTime()', 1000);

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.

-- 
 (c) John Stockton, nr London, UK.    ?@merlyn.demon.co.uk     Turnpike v6.05.
 Website  <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
 PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
 Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

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

#8552

On Tue, 22 Nov 2011 20:05:42 +0000, Dr J R Stockton
<reply1147@merlyn.demon.co.uk> wrote:

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

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



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

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

#8573

Swifty wrote:

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

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

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

#8596

On Wed, 23 Nov 2011 22:30:25 +0100, Zlatko ?uri? <zladuric@gmail.com>
wrote:

>Or is there some other important info coming in with the page 
>reload?

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

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

[toc] | [prev] | [standalone]

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

csiph-web