Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > getday() doesn't agree with system clock

Reply
Thread Tools

getday() doesn't agree with system clock

 
 
Swifty
Guest
Posts: n/a
 
      11-21-2011
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
 
Reply With Quote
 
 
 
 
Denis McMahon
Guest
Posts: n/a
 
      11-21-2011
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
 
Reply With Quote
 
 
 
 
Elegie
Guest
Posts: n/a
 
      11-21-2011
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.
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      11-21-2011
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
 
Reply With Quote
 
SAM
Guest
Posts: n/a
 
      11-21-2011
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 ?

--
Stphane Moriaux avec/with iMac-intel
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      11-21-2011
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$(E-Mail Removed)> (2004)
 
Reply With Quote
 
Swifty
Guest
Posts: n/a
 
      11-21-2011
On 21 Nov 2011 08:49:14 GMT, Denis McMahon <(E-Mail Removed)>
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
 
Reply With Quote
 
Scott Sauyet
Guest
Posts: n/a
 
      11-21-2011
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
 
Reply With Quote
 
Elegie
Guest
Posts: n/a
 
      11-21-2011
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.
 
Reply With Quote
 
Dr J R Stockton
Guest
Posts: n/a
 
      11-22-2011
In comp.lang.javascript message <thqjc7tjcififr5ms9bbrs7v46ivmopfj6@4ax.
com>, Mon, 21 Nov 2011 06:19:22, Swifty <(E-Mail Removed)>
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Updating DTD to agree with its use in doc's christopher.c.brewster@lmco.com XML 5 01-26-2005 10:21 PM
ZipOutputStream, ZipFile and Linux unzip do not agree on the file count in zip C B Java 4 11-10-2004 11:13 AM
Reviews: when Dave, Phil, Steve don't agree - comments? CR Optiker Digital Photography 14 11-13-2003 11:51 PM
full screen vs letterbox...can't we agree on both Scott Mitchell DVD Video 91 10-03-2003 03:31 AM
I agree Per Computer Support 3 09-18-2003 07:30 PM



Advertisments