MediaWiki talk:Gadget-UTCLiveClock.js

Update February 2011
I've updated the script to be fully compatible with Vector and 1.17 while still being compatible with Monobook and 1.16. It has been tested in the following set-ups: See also 74740. Krinkle 14:57, 1 February 2011 (UTC)
 * 1.16wmf4 Vector (MediaWiki.org)
 * 1.16wmf4 Monobook (MediaWiki.org)
 * 1.17alpha Vector (prototype)
 * 1.17alpha Monobook (prototype)
 * trunk Vector (TranslateWiki)
 * trunk Monobook (TranslateWiki)
 * I already did it attranslatewiki:MediaWiki:Gadget-UTCLiveClock.jsMax Semenik 15:07, 1 February 2011 (UTC)
 * I didn't see that but now that I see it, I must say that it doesn't work (function showTime is not defined when the ready-statement fires early) and it still removes the tag, which was kindof the main bug. 15:21, 1 February 2011 (UTC)
 * Heh, someone broke it. Again. Max Semenik 18:55, 1 February 2011 (UTC)

Use on a Style-sheet
Would this code work, for all users on compatible skins, if simply placed on MediaWiki:Common.js? --George2001hi 09:48, 26 April 2011 (UTC)
 * Yes, it should work fine (its definition doesn't indicate any dependencies). Helder 11:42, 18 October 2012 (UTC)

Documentation for gadget authors
We're trying to start a library for gadget authors to use. Please check it out and post any questions or comments there. -- ☠ MarkAHershberger ☢ (talk) ☣ 01:40, 9 March 2012 (UTC)

Improvment of the clock gadget
This gadget and other clocks have the common problem of skipping some seconds : for example, the clock may display 11:20:35 just after 11:20:33 (skipping 11:20:34). It occurs because display function may be called at bad moment within the second (for the previous example at 11:20:33.995 then at 11:20:35.005).

I propose to improve the gadget by using the millisecond value to schedule next execution at hh:mm:ss.100 which give enough time (900ms) to execute the display function.

In the showTime function : --DavidL (talk) 11:04, 23 June 2012 (UTC)


 * Did this ever get incorporated? Sounds like a sound idea to me. — T13   ( C • M • Click to learn how to view this signature as intended ) 16:47, 27 March 2013 (UTC)


 * The above screenshot image shows another difference between the 2 versions of the gadget: the modified one (on the right side, displaying local time UTC+0200) always display time about 1 second before the former one.
 * --DavidL (talk) 09:57, 21 April 2013 (UTC)
 * (Hexmode asked me to leave a message) You could also use a fixed delay of  instead of   or instead of  . That should also fix the problem. Using   might also be useful – though the benefit (no overhead from inactive tabs, and saving browser redraws by letting the browser pick the time) might not be worth the cost since it'd be a no-op most of the time (up to 60 frames a second). Both the suggestion here  and a fixed   will work fine I think. Krinkle (talk) 17:58, 20 May 2013 (UTC)
 * Any fixed delay won't fix the problem. A variable delay is necessary to adjust time at each iteration according to client current CPU usage.
 * With a fixed delay of 900ms (your suggestion), you may have
 * (CPU is not busy):
 * 11:00:05.100
 * 11:00:06.000
 * 11:00:06.900
 * 11:00:07.800
 * (CPU is busy, script sleep for more than the specified 900ms):
 * 11:00:05.100
 * 11:00:06.001 (+1 ms)
 * 11:00:06.905 (+4 ms)
 * 11:00:07.811 (+6 ms)
 * -> 11:00:06 is displayed twice in both cases.
 * With a fixed delay of 1000ms (current version), you may have
 * (CPU is not busy):
 * 11:00:05.995
 * 11:00:06.995
 * 11:00:07.995
 * 11:00:08.995
 * (CPU is busy, script sleep for more than the specified 1000ms):
 * 11:00:05.995
 * 11:00:06.998 (+3 ms)
 * 11:00:08.001 (+3 ms)
 * 11:00:09.008 (+7 ms)
 * -> 11:00:07 is not displayed at all. Problem arise when CPU is a bit busy but also because displaying take a non-zero time which depends on client CPU speed.
 * With an adjusted time as I suggest, you may have
 * (CPU is not busy, script sleep for an adjusted delay):
 * 11:00:05.995 (sleep for 1100-ms = 105ms)
 * 11:00:06.100 (sleep for 1100-ms = 1000ms)
 * 11:00:07.100 (sleep for 1100-ms = 1000ms)
 * 11:00:08.100 (sleep for 1100-ms = 1000ms)
 * (CPU may be busy or not, script sleep for an adjusted delay):
 * 11:00:05.995 (sleep for 1100-ms = 105ms)
 * 11:00:06.109 (+9 ms) (sleep for 1100-ms = 991ms)
 * 11:00:07.111 (+11 ms) (sleep for 1100-ms = 989ms)
 * 11:00:08.105 (+5 ms)
 * -> The time is always displayed near the 100ms within the second. The timer have a maximum late delay of 899 ms to absorb CPU load effect.
 * --DavidL (talk) 13:35, 25 May 2013 (UTC)
 * Your sample code shows that a fixed delay of 900ms clearly does work. It doesn't skip any seconds (granted that the thread doesn't block for more than a second, in which case it'll skip no matter what we do). It does result in the same value for the second indicator twice (you suggested this only happens with a busy CPU but it will happen without that too, the 900 increment will naturally at some point end up going from 900 instead of rolling over to the next second). But it won't skip any and it fixes the problem.
 * However, from a user experience point of view the 900 increment introduces a different problem, namely that it will routinely cause the second to appear to "freeze" for 1800ms and then naturally catch up again through the 100ms negative overlaps. The dynamically calculated increments are as good as it gets within the unreliable nature of  (short of going full-on with   and joining the available redraw frames if available and only updating if the second has changed). Krinkle (talk) 10:09, 26 May 2013 (UTC)