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 <a> tag, which was kindof the main bug. 15:21, 1 February 2011 (UTC)

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 :

varms=now.getUTCMilliseconds();// To adjust next schedule time/* ... */setTimeout(function(){showTime($target);},1100-ms);// Adjusted time

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.

(Hexmode asked me to leave a message)You could also use a fixed delay of 900 instead of 1000 or instead of 1100 - getMs(). That should also fix the problem. Using requestAnimationFrame 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 (1100 - ms) and a fixed 900 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.

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 < 100 to > 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 setTimeout (short of going full-on with requestAnimationFrame and joining the available redraw frames if available and only updating if the second has changed). Krinkle (talk) 10:09, 26 May 2013 (UTC)

MWDeprecationWarning: Use of "appendCSS" property is deprecated.[edit]

Is it correct, that this clock is supposed to display the server time, not the local time? Is there some parameter to adjust ist?--[[User:Bmrberlin| Bernd M.]] (talk) 10:54, 22 April 2015 (UTC)

That is correct, no there isn't. en:Technical 13/Scripts/Gadget-LiveClock.js (doc) is a userscript version that displays your local time (UTC on mouseover). I haven't used it in some time, so if it doesn't work, just let me know and I'll make any needed fixes. To use the script:

I've been a longtime user of this gadget. One problem I've noticed many times is that the clock loads after the rest of the toolbar. This can causes the user to accidentally log out. Here's a typical scenario:

editor visits Wikipedia

page starts rendering

editor quickly moves mouse to "Contributions" link and clicks on it

editor realizes they forgot to let clock load

finally load of clock, which pushes all the toolbar items to the left

finally browser starts to process click, which is now over "Log out" instead of "Contribution".

editor gets logged out.

curses ensue

The speed of the computer plays an important role here but it can happen even on fast computers for reckless mouse clickers like me.

Is it technically feasible to have this gadget load before the toolbar items? Jason Quinn (talk) 23:12, 20 August 2015 (UTC)

I would prefer if the link were moved just a little bit below the portlet menu. E.g. by creating a second<ulstyle="float: right;"><liid="utcdate"><ahref="...purge">hh:mm:ss</a></li></ul>inside the<divid="p-personal">That way, the default links would not be moved at all. Helder 18:16, 29 August 2015 (UTC)

This happened to me once, recently. I think I am more used to the page scrolling up and down than those links moving, making Helder's idea look better. PC-XT (talk) 06:56, 15 February 2016 (UTC)

Hello all. I've drafted a new version of this gadget at User:Mr. Stradivarius/UTCLiveClock.js that, when coupled with the CSS in my common.css, prevents the clock from making the personal toolbar jump to the left when it loads. I've already copied the CSS to these files:

All that needs to be done to deploy it on this wiki is to copy the JS over, and add the new CSS pages to MediaWiki:Gadgets-definition. For other wikis, the CSS files will need to be copied, and MediaWiki:Gadgets-definition updated as well.

Getting rid of the jumping effect would be a huge plus in my opinion, but there are downsides too. Currently, you can change the location of the clock by adding a UTCLiveClockConfig object to your personal .js file, but this won't be possible with my new version. This is because we need to reserve space for the gadget using CSS only, and I can't think of a way to make this work if the location of the clock isn't guaranteed to be the same every time.

I made a search of all Wikimedia wikis using a script that I made, and I found three users who use UTCLiveClockConfig to change the location of the clock. David Levy, Gamren, and HarJIT: would it be OK to make the change? If you really want to have the clock in a non-default location, let me know - if I make some adjustments to the JavaScript, and if you load the script directly from your personal .js, it is possible.

Also, I would be grateful if people could review my code. If there's something I could do better - or something I've done wrong - then it would be better to find out now, rather than after the code has been deployed, as this gadget is widely used. Best — Mr. Stradivarius♪ talk ♪ 14:31, 28 September 2017 (UTC)

If all you've done with your JS is add those two .css() lines of code, it all looks good to me. Thanks for doing this, and finding the people who would be adversely affected. Perhaps they only moved the positioning because they were sick of it jumping around, too? — MusikAnimaltalk 15:24, 28 September 2017 (UTC)

I don't really care where the clock is, as long as its loading doesn't cause jumping.__Gamren (talk) 15:56, 28 September 2017 (UTC)

I'm not actually moving the clock as far as Wikimedia wikis are concerned (I'm placing it before a non-existent ID, which just appends it). I specify it because I import my Wikimedia MetaWiki global.js in my Wikia global.js, and Wikia's notifications code on their version of Monobook will fold the clock into the notification area (which breaks it) unless it is placed before rather than after the #pt-wall-notifications. But I'm loading the gadget with jQuery.getScript("//www.mediawiki.org/w/index.php?action=raw&ctype=text/javascript&title=MediaWiki:Gadget-UTCLiveClock.js&oldid=2155162"); specifying an oldid, so that wouldn't be affected by the changes. So by all means, go ahead. -- HarJIT (talk) 18:11, 28 September 2017 (UTC)

Thank you all for your feedback. I've gone ahead and rolled the gadget out here and at enwiki. I would do it at other wikis too, but I only have admin rights here and at enwiki (well, and testwiki too). Maybe we could put together a mass message for wikis that have this gadget installed? — Mr. Stradivarius♪ talk ♪ 15:25, 29 September 2017 (UTC)

@Mr. Stradivarius: I am an admin of en.wikt (which is where I have it installed), and da.wikt. If you can tell me exactly what to do, I can do it.__Gamren (talk) 07:38, 5 October 2017 (UTC)

@Mr. Stradivarius: Okay, now it does reserve space, but a bit too much, so the clock skips right instead of left when loading.__Gamren (talk) 15:07, 6 October 2017 (UTC)

@Gamren: Yes, I had a lot of problems like this when adding the space-reserving code. The clock is just added as an item inside an unordered list, which means it can have a different size depending on how exactly the browser chooses to render it. To make the space-reserving code work I needed to change that into a specific width in em, rather than just letting the browser decide the space automatically, so it's very possible that it might not work 100% correctly on all browsers in both supported skins (Vector and Monobook). Could you tell me what skin you are using, and what browser? Best — Mr. Stradivarius♪ talk ♪ 00:13, 7 October 2017 (UTC)

@Mr. Stradivarius: hey, in ruwiki, we've done an analogous change back in February (we have an independent gadget). We use an invisible :after pseudoelement with content:"00:00:00", then remove it in the script, instead of having fixed widths. We have no known issues, maybe you could use our idea. See w:ru:MediaWiki:Gadget-UTCLiveClock.js (the gadget itself), w:ru:MediaWiki:Gadget-UTCLiveClock-helperStyles.css (the peer gadget). Our gadget is also able to open the purged page in the new tab (when pressing Ctrl, which browsers use for opening new tabs). (We don't use addPortletLink for some reason; one of our admins, DonRumata, replaced it with a direct node insertion with an edit summary "compatability with the compact personal panel", maybe he could clarify.)

I'm sorry for not trying to distribute the change (forgot that it's a global one). Jack who built the house (talk) 08:21, 12 October 2017 (UTC)

The current edition has one more flaw: if I click whitespace next to the link, not the link itself, the page will be purged. Fixed in the obvious way. Jack who built the house (talk) 15:36, 12 October 2017 (UTC)

@Mr. Stradivarius: Apologies for overlooking this thread until now. I just want to confirm that I was customizing the clock's location specifically to prevent the menu from jumping, so I unreservedly endorse this change and thank you for your thoughtful efforts in this area. —David Levy 21:03, 12 October 2017 (UTC)

This is just to confirm that I am not experiencing jumping anymore, for which I am thankful.__Gamren (talk) 17:53, 2 November 2017 (UTC)