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

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

Re: OT: Displaying current time on a website

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: OT: Displaying current time on a website Rhino <no_offline_contact_please@example.com> - 2013-11-27 16:15 -0500
    Re: OT: Displaying current time on a website Denis McMahon <denismfmcmahon@gmail.com> - 2013-11-28 01:11 +0000
      Re: OT: Displaying current time on a website "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2013-11-28 11:20 +0200
        Re: OT: Displaying current time on a website Denis McMahon <denismfmcmahon@gmail.com> - 2013-11-29 00:12 +0000
          Re: OT: Displaying current time on a website Andrew Poulos <ap_prog@hotmail.com> - 2013-11-29 13:51 +1100
          Re: OT: Displaying current time on a website Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-29 10:58 +0100
      Re: OT: Displaying current time on a website Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-11-29 21:30 +0000
    Re: OT: Displaying current time on a website Stefan Weiss <krewecherl@gmail.com> - 2013-11-28 23:09 +0100
      Re: OT: Displaying current time on a website tony@mountifield.org (Tony Mountifield) - 2013-11-28 23:24 +0000
        Re: OT: Displaying current time on a website tony@mountifield.org (Tony Mountifield) - 2013-11-29 13:12 +0000
          Re: OT: Displaying current time on a website Stefan Weiss <krewecherl@gmail.com> - 2013-11-29 14:39 +0100
          Re: OT: Displaying current time on a website Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-11-30 20:35 +0000
            Re: OT: Displaying current time on a website "Evertjan." <exjxw.hannivoort@interxnl.net> - 2013-12-01 07:57 +0000

#22197 — Re: OT: Displaying current time on a website

On 2013-11-27 2:41 PM, Christoph Michael Becker wrote:
> Rhino wrote:
>
>> On 2013-11-26 5:15 PM, Rhino wrote:
>>> On 2013-11-25 8:26 PM, Beauregard T. Shagnasty wrote:
>>>>
>>>> BTW, your sample page with the time display fails if JavaScript is
>>>> disabled, as it is in my browsers nearly all the time.
>>>>
>>> Good point. I'll replace the Javascript with a Server Side Include of
>>> DATE_LOCAL.
>>>
>>
>> Blast! Now I remember why I liked the JavaScript approach over the SSI
>> approach: the JavaScript approach actually updated the seconds on the
>> clock once every second. The SSI approach does NOT refresh the time
>> every second.
>>
>> What is the best way of displaying the current time so that the seconds
>> advance once per second? (Again, I'm assuming the customer can't be
>> persuaded to stop showing the current time on the web page.)
>
> In your case I would emit the current time with SSI, and update the time
> with browser side scripting -- if that is disabled or not available at
> all, the visitor sees the time of the request, at least.  However, both
> times may be considerably different due to timezone differences.
>
Interesting idea. How would I get the time from SSI but update it every 
second via my HTML? I've got the SSI part already but I'm at a loss how 
to update that time  on an ongoing basis.

> F'up to comp.lang.javascript
>


-- 
Rhino

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [next] | [standalone]

#22203

On Wed, 27 Nov 2013 16:15:09 -0500, Rhino wrote:

>> F'up to comp.lang.javascript

Most computer users have a clock somewhere on their screen already, 
showing the time zone(s) that they want, unless they made a conscious 
decision not to have one there.

Why do you want to use cpu resources on the client system in duplicating 
a feature that probably already exists?

If you want a "page generated at time on date" then use server side code 
to do so, but really, displaying a clock to the user, no, just don't do 
it.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#22204

2013-11-28 3:11, Denis McMahon wrote:

> Most computer users have a clock somewhere on their screen already,
> showing the time zone(s) that they want, unless they made a conscious
> decision not to have one there.

Well, yes - on desktop screens. And displaying current time on a web 
page is mostly pointless or worse. But...

> Why do you want to use cpu resources on the client system in duplicating
> a feature that probably already exists?

For example, if you have created an HTML5 application 
(HTML+CSS+JavaScript that works like an application in a browser) that 
you expect people to use mostly in pocket-size devices, there might be 
good reasons for including time display. Perhaps even if the time does 
not relate to the functionality of the application. After all, many 
people have no watch these days, they look at their "phone" to see what 
time it is.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

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

#22212

On Thu, 28 Nov 2013 11:20:25 +0200, Jukka K. Korpela wrote:

> 2013-11-28 3:11, Denis McMahon wrote:

>> Most computer users have a clock somewhere on their screen already,
>> showing the time zone(s) that they want, unless they made a conscious
>> decision not to have one there.

> Well, yes - on desktop screens. And displaying current time on a web
> page is mostly pointless or worse. But...

>> Why do you want to use cpu resources on the client system in
>> duplicating a feature that probably already exists?

> For example, if you have created an HTML5 application
> (HTML+CSS+JavaScript that works like an application in a browser) that
> you expect people to use mostly in pocket-size devices, there might be
> good reasons for including time display. Perhaps even if the time does
> not relate to the functionality of the application. After all, many
> people have no watch these days, they look at their "phone" to see what
> time it is.

Even so, if they want to view the time on screen there's probably a more 
efficient native method in the device than doing so through an 
interpreted scripting language. If they don't want to view the time on 
screen, then why are you taking up display real estate, cpu cycles and 
battery power in doing so?

Case 1 - user wants to know the time always, at all costs:

User probably has a device that either directly, or through an app they 
have running, always displays the time somewhere on the screen. You don't 
need to duplicate what the user already has.

Case 2 - user isn't so bothered about knowing the time:

Why waste resources doing it - if user wants it they can probably get it 
more efficiently natively or with an app. If the user doesn't want it, 
you don't need to use resources delivering it.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#22213

On 29/11/2013 11:12 AM, Denis McMahon wrote:
> On Thu, 28 Nov 2013 11:20:25 +0200, Jukka K. Korpela wrote:
>
>> 2013-11-28 3:11, Denis McMahon wrote:
>
>>> Most computer users have a clock somewhere on their screen already,
>>> showing the time zone(s) that they want, unless they made a conscious
>>> decision not to have one there.
>
>> Well, yes - on desktop screens. And displaying current time on a web
>> page is mostly pointless or worse. But...
>
>>> Why do you want to use cpu resources on the client system in
>>> duplicating a feature that probably already exists?
>
>> For example, if you have created an HTML5 application
>> (HTML+CSS+JavaScript that works like an application in a browser) that
>> you expect people to use mostly in pocket-size devices, there might be
>> good reasons for including time display. Perhaps even if the time does
>> not relate to the functionality of the application. After all, many
>> people have no watch these days, they look at their "phone" to see what
>> time it is.
>
> Even so, if they want to view the time on screen there's probably a more
> efficient native method in the device than doing so through an
> interpreted scripting language. If they don't want to view the time on
> screen, then why are you taking up display real estate, cpu cycles and
> battery power in doing so?
>
> Case 1 - user wants to know the time always, at all costs:
>
> User probably has a device that either directly, or through an app they
> have running, always displays the time somewhere on the screen. You don't
> need to duplicate what the user already has.
>
> Case 2 - user isn't so bothered about knowing the time:
>
> Why waste resources doing it - if user wants it they can probably get it
> more efficiently natively or with an app. If the user doesn't want it,
> you don't need to use resources delivering it.
>
Case 3 - the hirer requested it

The hirer - the one paying for the work - requested it so that's what 
the OP needs to do. (If you are in a position to turn down work then 
"lucky you"!)

Andrew Poulos

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

#22214

Denis McMahon wrote:

> On Thu, 28 Nov 2013 11:20:25 +0200, Jukka K. Korpela wrote:
>> 2013-11-28 3:11, Denis McMahon wrote:
>>> Most computer users have a clock somewhere on their screen already,
>>> showing the time zone(s) that they want, unless they made a conscious
>>> decision not to have one there.
>> 
>> Well, yes - on desktop screens. And displaying current time on a web
>> page is mostly pointless or worse. But...
>> 
>>> Why do you want to use cpu resources on the client system in
>>> duplicating a feature that probably already exists?
>> 
>> For example, if you have created an HTML5 application
>> (HTML+CSS+JavaScript that works like an application in a browser) that
>> you expect people to use mostly in pocket-size devices, there might be
>> good reasons for including time display. Perhaps even if the time does
>> not relate to the functionality of the application. After all, many
>> people have no watch these days, they look at their "phone" to see what
>> time it is.
> 
> Even so, if they want to view the time on screen there's probably a more
> efficient native method in the device than doing so through an
> interpreted scripting language. […]

It is a common misconception that source code in a scripting language would 
be interpreted as it is.  Instead, code written for ECMAScript 
implementations in browsers, like JavaScript, JScript aso., is compiled into 
bytecode or native machine code.  Only the bytecode, if that, is then 
interpreted/executed by a Virtual Machine (VM).  This applies to several 
other scripting languages that are not based on ECMAScript, too, for example 
PHP and Python.  It is therefore wrong to say “interpreted scripting 
language”.

See also: <http://en.wikipedia.org/wiki/V8_(JavaScript_engine)>

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#22217

In comp.lang.javascript message <l7657v$hgk$2@dont-email.me>, Thu, 28
Nov 2013 01:11:27, Denis McMahon <denismfmcmahon@gmail.com> posted:

>On Wed, 27 Nov 2013 16:15:09 -0500, Rhino wrote:
>
>>> F'up to comp.lang.javascript
>
>Most computer users have a clock somewhere on their screen already,
>showing the time zone(s) that they want, unless they made a conscious
>decision not to have one there.

You do not, I think, mean time zone.  The UK and Iceland are in the same
time zone, so have the same time in Winter; but they have different time
in Summer.  One should not pander to the ignorance of the Microsofties.

Most have their computer set to current civil time.  But sometimes one
is more interested in the time elsewhere.

In the computer that I am at present using, the default time display is
tiny, in hours and minutes.  I like to be able to see a larger display,
with seconds.

JavaScript is not necessarily written ***for*** the distant client of a
Web server, even when it is made available thus : my js-alarm.htm is
written for ***ME***, and I put it on the server because others might
like to have a copy.

My js-date5.htm#SLGC gives current date and time by default in 8 places,
plus local & GMT; and a reader can subtract or add places at will, using
a TZ string.

>Why do you want to use cpu resources on the client system in duplicating
>a feature that probably already exists?

Probably is not certainly.

>If you want a "page generated at time on date" then use server side code
>to do so, but really, displaying a clock to the user, no, just don't do
>it.

But the page may not have been generated on a server.

Never assume that a questioner belongs to the majority.

-- 
 (c) John Stockton, nr London, UK.   E-mail, see Home Page.    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]

#22209

On 2013-11-27 22:15, Rhino wrote:
> On 2013-11-27 2:41 PM, Christoph Michael Becker wrote:
>> In your case I would emit the current time with SSI, and update the time
>> with browser side scripting -- if that is disabled or not available at
>> all, the visitor sees the time of the request, at least.  However, both
>> times may be considerably different due to timezone differences.
>>
> Interesting idea. How would I get the time from SSI but update it every 
> second via my HTML? I've got the SSI part already but I'm at a loss how 
> to update that time  on an ongoing basis.

I'd actually like to see an implementation of that. Counting up seconds
may seem trivial at a first glance, but how would you go about writing a
clock display (with second precision) that is

a) as accurate as possible (relative to the local time on the client)
b) as "smooth" as possible (does not increment the seconds display by
more than 1, if it can be avoided)
c) can handle the client being busy for extended periods (caused by
things like complex calculations, synchronous HTTP requests, high CPU
load, etc)
d) doesn't tax the client by using very short timeouts or intervals

I've got some ideas about how to implement it, but I'm curious about
what solutions other people might come up with.

- stefan

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

#22211

In article <l78evn$7jc$1@news.albasani.net>,
Stefan Weiss  <krewecherl@gmail.com> wrote:
> On 2013-11-27 22:15, Rhino wrote:
> > On 2013-11-27 2:41 PM, Christoph Michael Becker wrote:
> >> In your case I would emit the current time with SSI, and update the time
> >> with browser side scripting -- if that is disabled or not available at
> >> all, the visitor sees the time of the request, at least.  However, both
> >> times may be considerably different due to timezone differences.
> >>
> > Interesting idea. How would I get the time from SSI but update it every 
> > second via my HTML? I've got the SSI part already but I'm at a loss how 
> > to update that time  on an ongoing basis.
> 
> I'd actually like to see an implementation of that. Counting up seconds
> may seem trivial at a first glance, but how would you go about writing a
> clock display (with second precision) that is
> 
> a) as accurate as possible (relative to the local time on the client)
> b) as "smooth" as possible (does not increment the seconds display by
> more than 1, if it can be avoided)
> c) can handle the client being busy for extended periods (caused by
> things like complex calculations, synchronous HTTP requests, high CPU
> load, etc)
> d) doesn't tax the client by using very short timeouts or intervals
> 
> I've got some ideas about how to implement it, but I'm curious about
> what solutions other people might come up with.

Here is what I came up with a while ago to provide a display of server
time independent of the client's local time setting. It assumes that
the client keeps good time, even though it is not in sync with the server.

Firstly clocktest.php (provides the start time in JS):

<!DOCTYPE html>
<html>
<head>
<title>Clock Test</title>
<style type="text/css">
body { font-family: Arial, Helvetica, sans-serif; text-align: center; }
a.link { text-decoration: none; color: #FF3399; font-weight: bold; }
a.link:hover { text-decoration: underline; }
</style>
<?php
$m=microtime();
$z=date('Z');
list($us,$s) = explode(' ',$m);
$start = ((float)$s+$z+(float)$us)*1000.;
?>
<!-- $m = "<?= $m ?>", $us = <?= $us ?>, $s = <?= $s ?>, $z = <?= $z ?> -->
<script type="text/javascript">
var serverstart=<?= $start ?>;  // JS uses milliseconds
</script>
<script type="text/javascript" src="clock.js"></script>
</head>

<body>
<h3>Current Time on Server - <span id="clock"></span></h3>
</body>
</html>

Secondly, clock.js (increments the time once per second):

var clientstart = new Date().getTime();

var days = ["Sun","Mon","Tue","Wed","Thu","Fri","Sat"];
var mths = ["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"];

// Custom formatting function - customize as required
Date.prototype.outputDate = function() {
        var d = this;
        var h = d.getUTCHours();
        var h12 = (h+11)%12 + 1;
        var ap = (h < 12)?'am':'pm';
        var m = ("0"+d.getUTCMinutes()).slice(-2);
        var s = ("0"+d.getUTCSeconds()).slice(-2);
        var t = days[d.getUTCDay()]
                +' '+d.getUTCDate()+' '+mths[d.getUTCMonth()]
                +' '+d.getUTCFullYear()
                +' '+h12+':'+m+':'+s+' '+ap;
        return t;
}

function update() {
        var clock = document.getElementById('clock');
        var clienttime = new Date().getTime();
        var servertime = new Date(serverstart + (clienttime-clientstart));
        //clock.innerHTML = servertime.toLocaleString();        // system standard format
        clock.innerHTML = servertime.outputDate();              // custom format above
        setTimeout(update,1000-(servertime%1000));
}

window.onload = update;

Any improvements gratefully received!

Cheers
Tony
-- 
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org

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

#22215

OK, a couple of corrections needed to my clock.js below...

In article <l78jc8$o49$2@softins.softins.co.uk>,
Tony Mountifield <tony@mountifield.org> wrote:
> In article <l78evn$7jc$1@news.albasani.net>,
> Stefan Weiss  <krewecherl@gmail.com> wrote:
> > On 2013-11-27 22:15, Rhino wrote:
> > > On 2013-11-27 2:41 PM, Christoph Michael Becker wrote:
> > >> In your case I would emit the current time with SSI, and update the time
> > >> with browser side scripting -- if that is disabled or not available at
> > >> all, the visitor sees the time of the request, at least.  However, both
> > >> times may be considerably different due to timezone differences.
> > >>
> > > Interesting idea. How would I get the time from SSI but update it every 
> > > second via my HTML? I've got the SSI part already but I'm at a loss how 
> > > to update that time  on an ongoing basis.
> > 
> > I'd actually like to see an implementation of that. Counting up seconds
> > may seem trivial at a first glance, but how would you go about writing a
> > clock display (with second precision) that is
> > 
> > a) as accurate as possible (relative to the local time on the client)
> > b) as "smooth" as possible (does not increment the seconds display by
> > more than 1, if it can be avoided)
> > c) can handle the client being busy for extended periods (caused by
> > things like complex calculations, synchronous HTTP requests, high CPU
> > load, etc)
> > d) doesn't tax the client by using very short timeouts or intervals
> > 
> > I've got some ideas about how to implement it, but I'm curious about
> > what solutions other people might come up with.
> 
> Here is what I came up with a while ago to provide a display of server
> time independent of the client's local time setting. It assumes that
> the client keeps good time, even though it is not in sync with the server.
> 
> Firstly clocktest.php (provides the start time in JS):
> 
> <!DOCTYPE html>
> <html>
> <head>
> <title>Clock Test</title>
> <style type="text/css">
> body { font-family: Arial, Helvetica, sans-serif; text-align: center; }
> a.link { text-decoration: none; color: #FF3399; font-weight: bold; }
> a.link:hover { text-decoration: underline; }
> </style>
> <?php
> $m=microtime();
> $z=date('Z');
> list($us,$s) = explode(' ',$m);
> $start = ((float)$s+$z+(float)$us)*1000.;
> ?>
> <!-- $m = "<?= $m ?>", $us = <?= $us ?>, $s = <?= $s ?>, $z = <?= $z ?> -->
> <script type="text/javascript">
> var serverstart=<?= $start ?>;  // JS uses milliseconds
> </script>
> <script type="text/javascript" src="clock.js"></script>
> </head>
> 
> <body>
> <h3>Current Time on Server - <span id="clock"></span></h3>
> </body>
> </html>
> 
> Secondly, clock.js (increments the time once per second):
> 
> var clientstart = new Date().getTime();
> 
> var days = ["Sun","Mon","Tue","Wed","Thu","Fri","Sat"];
> var mths = ["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"];
> 
> // Custom formatting function - customize as required
> Date.prototype.outputDate = function() {
>         var d = this;
>         var h = d.getUTCHours();
>         var h12 = (h+11)%12 + 1;
>         var ap = (h < 12)?'am':'pm';
>         var m = ("0"+d.getUTCMinutes()).slice(-2);
>         var s = ("0"+d.getUTCSeconds()).slice(-2);
>         var t = days[d.getUTCDay()]
>                 +' '+d.getUTCDate()+' '+mths[d.getUTCMonth()]
>                 +' '+d.getUTCFullYear()
>                 +' '+h12+':'+m+':'+s+' '+ap;
>         return t;
> }
> 
> function update() {
>         var clock = document.getElementById('clock');
>         var clienttime = new Date().getTime();
>         var servertime = new Date(serverstart + (clienttime-clientstart));
>         //clock.innerHTML = servertime.toLocaleString();        // system standard format
>         clock.innerHTML = servertime.outputDate();              // custom format above
>         setTimeout(update,1000-(servertime%1000));
> }
> 
> window.onload = update;

Unfortunately, I had some confusion in update() between millisecond times
and Date objects, and was not using servertime correctly. Here is a corrected version:

function update() {
        var clock = document.getElementById('clock');
        var clienttime = new Date().getTime();
        var servertime = serverstart + (clienttime-clientstart);
        //clock.innerHTML = new Date(servertime).toLocaleString();      // system standard format
        clock.innerHTML = new Date(servertime).outputDate();            // custom format above
        setTimeout(update,1000-(servertime%1000));
}

Cheers
Tony
-- 
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org

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

#22216

On 2013-11-29 14:12, Tony Mountifield wrote:
>         var clienttime = new Date().getTime();
>         var servertime = serverstart + (clienttime-clientstart);
...
>         setTimeout(update,1000-(servertime%1000));

Yes, this is pretty much what I had in mind. It could be simplified a
little, by combining `serverstart` and `clientstart` into a fixed
`clientoffset`, or by using `+new Date()`, but the principle remains the
same. If updating the display takes a "long" time (>1ms), it might be
better to call setTimeout() before displaying the new time.

I think the important points in this exercise are

- use setTimeout() instead of setInterval()
- read the current client time on every update
- calculate the number of ms left until the next tick, and use that
  value in setTimeout()

Nicely done.

- stefan

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

#22220

In comp.lang.javascript message <l7a3rn$7d6$1@softins.softins.co.uk>,
Fri, 29 Nov 2013 13:12:23, Tony Mountifield <tony@mountifield.org>
posted:

>function update() {
>        var clock = document.getElementById('clock');
>        var clienttime = new Date().getTime();
>        var servertime = serverstart + (clienttime-clientstart);
>        //
>        clock.innerHTML = new Date(servertime).outputDate();
>        setTimeout(update,1000-(servertime%1000));
>}

I think you do not need to ask to create a second Date Object.  OTOH,
the system could easily choose not to create the first one.


function update() {
        var clock = document.getElementById('clock');           //// A
        var clienttime = new Date().getTime();
        var servertime = serverstart + (clienttime-clientstart);
        clienttime.setTime(servertime)                          //// B
        clock.innerHTML = clienttime.outputDate();              //// C
        setTimeout(update, 1000-(servertime%1000));
}

A) Outside the function will save a little execution time
B) Added
C) Altered

Now rename clienttime to suit the new code.

UNTESTED.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

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

#22221

Dr J R Stockton wrote on 30 nov 2013 in comp.lang.javascript:

> I think you do not need to ask to create a second Date Object.  OTOH,
> the system could easily choose not to create the first one.
> 
> 
> function update() {
>         var clock = document.getElementById('clock');           //// A
>         var clienttime = new Date().getTime();
>         var servertime = serverstart + (clienttime-clientstart);
>         clienttime.setTime(servertime)                          //// B
>         clock.innerHTML = clienttime.outputDate();              //// C
>         setTimeout(update, 1000-(servertime%1000));

Methinks the first 1000 on this line should be adapted to accomodate for 
the resolution of the servertime, since that servertime is obviously 
rounded down to it's resolution.

So if the resolution is 0.1 second: 

setTimeout( update, 900 - (servertime % 1000) );

And if the resolution is 1 second: 

setTimeout( update, 500 );


>}
> 
> A) Outside the function will save a little execution time
> B) Added
> C) Altered
> 
> Now rename clienttime to suit the new code.
> 

[toc] | [prev] | [standalone]

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

csiph-web