Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.chainon-marquant.org!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <3002626.SPkdTlGXAF@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Mon, 21 Nov 2011 10:20:46 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit Subject: Re: getday() doesn't agree with system clock Newsgroups: comp.lang.javascript References: Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 98 NNTP-Posting-Date: 21 Nov 2011 10:20:47 CET NNTP-Posting-Host: ba13fb63.newsspool3.arcor-online.net X-Trace: DXC=Sf:^Q:XbN1fOKO]LCQ@0g`McF=Q^Z^V3h4Fo<]lROoRa8kF 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: 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