getday() doesn't agree with system clock

S

Swifty

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

Denis McMahon

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
 
E

Elegie

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

Hello,

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

Thomas 'PointedEars' Lahn

Swifty said:
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'.

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
 
T

Thomas 'PointedEars' Lahn

Thomas said:
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.
 
S

Swifty

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

Scott Sauyet

Elegie said:
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
 
E

Elegie

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

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

Because it is /relatively/ improbable :)

Cheers,
Elegie.
 
D

Dr J R Stockton

In comp.lang.javascript message <thqjc7tjcififr5ms9bbrs7v46ivmopfj6@4ax.
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.
 
S

Swifty

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

Zlatko Äurić

Swifty said:
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?
 
S

Swifty

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

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top