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:

• 1.16wmf4 Vector (MediaWiki.org)
• 1.16wmf4 Monobook (MediaWiki.org)
• 1.17alpha Vector (prototype)
• 1.17alpha Monobook (prototype)
• trunk Vector (TranslateWiki)
• trunk Monobook (TranslateWiki)

See also rev: 74740. Krinkle 14:57, 1 February 2011 (UTC)

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 <a> 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 :

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

--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 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.

--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 < 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.

I'm getting the error above on Portuguese Wikipedia. Could someone update the gadget? Krinkle? –Helder 12:23, 9 November 2013 (UTC)

 Done, Thanks! Krinkle (talk) 20:27, 3 December 2013 (UTC)

Mediawiki Version 1.24.2

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:

mw.loader.load( '//en.wikipedia.org/w/index.php?title=User:Technical 13/Scripts/Gadget-LiveClock.js&action=raw&ctype=text/javascript' );//[[User:Technical 13/enwpScripts]]

needs to be added you Special:MyPage/common.js or meta:Special:MyPage/global.js depending on if you only want it to work on the current wiki or all WMF wikis. — {{U|Technical 13}} (e • t • c) 17:53, 22 April 2015 (UTC)

:@Technical 13

Thank you for this quick response.--[[User:Bmrberlin| Bernd M.]] (talk) 18:27, 22 April 2015 (UTC)

causes unwanted log out clicks

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:

1. editor visits Wikipedia
2. page starts rendering
3. editor quickly moves mouse to "Contributions" link and clicks on it
4. editor realizes they forgot to let clock load
5. finally load of clock, which pushes all the toolbar items to the left
6. finally browser starts to process click, which is now over "Log out" instead of "Contribution".
7. editor gets logged out.
8. 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

<ul style="float: right;"><li id="utcdate"><a href="...purge">hh:mm:ss</a></li></ul>

inside the

<div id="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)

Please merge with MediaWiki:Gadget-LocalLiveClock.js

Can we made this gadget obsolete per option? The variable can be read also from the user-settings #Time-offset. → User: Perhelion 23:12, 12 May 2016 (UTC)

New version, prevents menu from jumping

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:

• MediaWiki:Gadget-UTCLiveClock.css - sets an explicit width for the clock; loaded as part of the clock gadget
• MediaWiki:Gadget-UTCLiveClock-pagestyles.css - reserves whitespace for the clock; loaded as a CSS-only peer gadget

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? — MusikAnimal ^talk 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)

@Gamren: Sure, no problem - I wrote some installation instructions at the top of MediaWiki:Gadget-UTCLiveClock.js. If any of that is not clear, let me know and I can help. Best — Mr. Stradivarius ^{♪ talk ♪} 14:10, 6 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)

Compact Personal Bar currently disabled. So my changes are not relevant. DonRumata (talk) 08:59, 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)

Time zones

Hi - is there any way to make the UTC live clock gadget work for certain time zones, not just UTC? Would be a handy addition for Wikimedia projects. I haven't actually found any wikimedia tool/template that shows the active time beside this gadget, so I don't think there's any alternative here. Ɱ (talk) 02:29, 11 May 2020 (UTC)

It should be fairly straightforward to get whatever time the user wanted in the Date object (replace getUTCHours, maybe getUTCMinutes for some timezones). I might try to do this at some point, but others are welcome to beat me to it --DannyS712 (talk) 03:13, 11 May 2020 (UTC)

I started looking into doing this - will code in my sandbox and submit at w:WP:Code review before implementing here. --DannyS712 (talk) 07:29, 11 May 2020 (UTC)

See w:Wikipedia:Code review/UTCLiveClock for discussion --DannyS712 (talk) 10:25, 11 May 2020 (UTC)

Documentation

The following comes from Tech/News/2020/31. I had to shorten the announcement and I didn't find any documentation to link to.

DannyS712, is correct to say "a user can set a different timezone by setting-up window.LiveClockTimeZone to the desired time zone name. This uses the TZ database time zones"? I'm not sure how to do this as an end-user. Would you document this somewhere? I can change the link on Tech News.

Thanks, Trizek (WMF) (talk) 14:34, 24 July 2020 (UTC)

@Trizek (WMF): yes, that is correct. You would add something like window.LiveClockTimeZone = 'America/Los_Angeles';, changing LA to whatever timezone you wanted --DannyS712 (talk) 21:30, 24 July 2020 (UTC)

Move gadget to far left of the user tools (i.e. username or language setting)

I have opted-in the clock gadget in a few or several language projects. I haven't yet opted-in the gadget in many others because its position at the far right (not the other "far-right") after "Log out" button makes the gadget hazardous to use. Furthermore, I accidentally get logged out while the gadget loads (kinda slowly?) when I clicked or tapped "Log out". Time for the gadget to move to the far left of the tools, i.e. left of a username (or language setting if available). If that's not either feasible or suitable, then relocate the gadget somewhere far from the "Log out" button. –George Ho (talk) 21:26, 28 October 2020 (UTC)

Hi. I have the same problem, and have a solution:

• Edit your global CSS file, and add the following lines:

#utcdate {
	position: absolute;
	left: 36px;
	top: 2px;
}

You can adjust the position values if necessary. The ones above are what I use for vector and monobook skins.

-- ◄ David L • discuter ► 09:58, 11 January 2021 (UTC)

Incorporate these ideas into the main Wikipedia Info Box

I have made a proposal at the Town Pump to include the current local time next to the Time Zone listing in the Wiki InfoBox.

For example, Los Angeles, CA's InfoBox Time Zone listing would read: UTC-08:00 (17:22 8 June, 2021).

Hopefully the time can update dynamically through your UTCLiveClock.js.

Any thoughts? Nbardach1638 (talk) 00:30, 9 June 2021 (UTC)

Clock adds itself to dropdown in Vector modern, Timeless and Minerva Neue skins

As raised in https://phabricator.wikimedia.org/T288607 this gadget adds itself to the dropdown menu of the new iteration of Vector, Timeless and Minerva.

This may or may not be desirable.

One way to fix this is to replace:

var node = mw.util.addPortletLink(
		'p-personal',
		mw.util.getUrl( null, { action: 'purge' } ),
		'',
		'utcdate'
	);

with

var node = mw.util.addPortletLink(
		'p-personal-more',
		mw.util.getUrl( null, { action: 'purge' } ),
		'',
		'utcdate'
	);

when

$('#p-personal-more').length

Jdlrobson (talk) 17:43, 11 August 2021 (UTC)

@Jdlrobson: I somehow tried to do this at euwiki and A) I did it wrongly and failed miserably or B) it didn't work. Old diff -Theklan (talk) 22:26, 15 August 2021 (UTC)

I’d write it in a more compact way as

	var node = mw.util.addPortletLink(
		document.getElementById( 'p-personal-more' ) ? 'p-personal-more' : 'p-personal',
		mw.util.getUrl( null, { action: 'purge' } ),
		'',
		'utcdate'
	);

(I used the native document.getElementById, which is supported by any browser from the last 18 years, and is probably faster than jQuery). However, this still only works on Vector—Timeless calls it personal-extra instead of p-personal-more, and Minerva doesn’t have a such dedicated place at all. By the way, I use Timeless on some wikis, and I actually like how the clock is hidden in the drop-down—I don’t use it as a clock anyway (I have one in my system tray, and that reliably shows the current time where I am, not UTC, not winter time at summertime etc.), I only use it to purge pages, but not that often that I’d want to waste space for it. Timeless’ huuuge search bar can be really useful at times. —Tacsipacsi (talk) 01:20, 20 August 2021 (UTC)

Sorry, tacsipacsi, I did that change but I can't find it outside the user-menu Edited: I just changed it at the UTC clock, not the local time clock. eu:MediaWiki:Gadget-UTCLiveClock.js. Thanks! -Theklan (talk) 18:32, 7 September 2021 (UTC)

The patch which Tacsipacsi wrote on 20 August works fine for me. Since IFAs on mw should fix this centralized version but not, I imported to jawiki locally and fixed it ja:special:diff/86959421. I hope I can replace our local version with mw fixed version in the future. --aokomoriuta (talk) 04:37, 11 December 2021 (UTC)

Add tooltip with UTC date upon hover?

Sometimes it can be confusing if the UTC day is +1, 0, or -1 to your current local day. This is especially true if you are travelling or working somewhere that you don't know the UTC offset, or just plain too tired to think properly. I think adding a tooltip upon hover would be nice. Jason Quinn (talk) 17:33, 2 November 2021 (UTC)

Why would that be useful? As I wrote above, I don’t use the clock as a clock, but even if I did, I don’t think the UTC date would be that important. I recently added the tooltip “Purge this page” to the huwiki fork of this gadget, I think it’s more useful (especially if this gadget is enabled by default on some wiki). —Tacsipacsi (talk) 22:27, 2 November 2021 (UTC)

It would have been useful just a moment ago. People were talking about a revert done in Thursday but it was late Friday for me. Just before midnight. Plus I'm very tired and I was blanking on which way to go for converting to UTC from my local time (which happens to be 12 hours off from EST). Sure it doesn't take but seconds to sort it out but it would of been handy to have. I'm not sure why we wouldn't want this tooltip. Jason Quinn (talk) 16:39, 29 July 2022 (UTC)

UTCLiveClock in Timeless

Could we change the position of clock in timeless skin to a place after "#personal" div object (just at the right side of your username in LTR system)? As it is not convenient to open the dropdown menu and click the clock link to purge the page, put it outside the dropdown menu would be a good idea. Stang 19:06, 14 March 2022 (UTC)

Do you really use it that much? Poor servers, doing that many extra parses. What I love about Timeless is its clean interface. In contrast to what happened to new Vector, its header contains really just the most important links, the less frequently used links like the clock are hidden in the dropdown menu—they’re just one extra click away, but they don’t distract me 99% of the time, when I don’t need them. (New Vector also started with just a few large buttons, but then people complained about the watchlist, so that has also been added outside of the dropdown menu, people complained about the clock, so that got moved out of the dropdown menu, and now we have a personal toolbar that has much more icons than Timeless, which are much larger than the links on legacy Vector, a really unorganized worst compromise.) —Tacsipacsi (talk) 22:50, 14 March 2022 (UTC)

Clock should not be simply considered as a link - imagine there is a clock on the wall, compared to a watch inside a drawer and you have to open the drawer every time you want to know what time is it now. At least the style of UTCLiveClock in vector-2022 looks pretty fine to me. Stang 13:40, 16 March 2022 (UTC)

Then it looks like we use the gadget quite differently. For me the clock function is not important at all: I have a clock on my wall, I have a clock on my OS taskbar, I don’t need yet another clock. I use this gadget only to purge pages, which is quite rare. I’d propose splitting this gadget if it wasn’t practically nearly impossible to do so around all of Wikimedia… And for me, the personal toolbar is broken into two lines; one line would still not be ideal, but much better. —Tacsipacsi (talk) 23:31, 16 March 2022 (UTC)

Is this time right?

Hey, whomever watches this page,

I have a clock in the upper right-hand corner that I think is this gadget that shows UTC time. But lately, I've noticed that it's slow, maybe by 10 or 20 seconds. It'll say, for example, 10:47:50 but the edit that was made has a time of 10:48. This seems to be a recent problem, in the past few weeks and I don't think it has anything to do with my computer. You might not think that a few seconds are important but there are some time-sensitive edits where it is. Anyone else notice this is occurring? Liz (talk) 01:59, 7 May 2022 (UTC)

@Liz: There’s not more than half a second discrepancy for me (I tested it manually, so I can’t measure it more precisely). The gadget gets the current time from your browser, while the timestamp in the signature is from the server, so it’s very well possible that your computer got out of sync (since it works for me, it’s less likely that the server is the one that’s out of sync). First you should check if network/Internet time is enabled. If it is, it may be a hardware issue; for example, once I’ve had a then-10-year-old computer on which I had to set the time after each startup because it “forgot” it while it was turned off. —Tacsipacsi (talk) 19:31, 7 May 2022 (UTC)

Problem showing clock in Vector 2022 skin

The clock can't be seen complete in Vector 2022 skin in English Wikipedia John123521 (talk) 12:40, 8 July 2022 (UTC)

Ideally, the clock would continue to display at the top of the screen at all times, instead of being stuck behind a menu. The point of a clock on the wall is that you can glance up and know what time it is. Jonesey95 (talk) 14:51, 19 July 2022 (UTC)

Indeed. +1 on this being an annoyance. 108.3.157.5 03:08, 19 September 2022 (UTC)

I prefer the current location of the clock, and would appreciate if it could be on that position even in Vector-2022, but if that does not work, I'd be okay with it being right aligned on the page title header in a non-black colour. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 10:28, 21 September 2022 (UTC)

Add clock to p-personal-sticky-header

It appears that the truncating of the clock has been fixed. I did note that the clock does not currently appear in the "pinned" user menu that renders when you scroll down the page. See task T325124. Jonesey95 (talk) 01:59, 14 December 2022 (UTC)

The issue with it not showing in the pinned user menu requires a fix here. That would mean looking for it with the ID "p-personal-sticky-header". The reason why it doesn't show right now is that the sticky header menu and the normal menu are different elements in the HTML, which means that the code here has to look and update two different lists. Dreamy Jazz (talk) 12:36, 14 December 2022 (UTC)

I've updated the gadget to add to both. In sticky header it must show in the sticky header dropdown as the rest of the sticky header does not currently support expansion. Jon (WMF) (talk) 16:34, 29 January 2023 (UTC)

Can the clock show next to the User menu, like before?

It would be very useful for this clock to be displayed to the right of the User menu icon, instead of within the user menu, as it was before. Is this possible? Jonesey95 (talk) 18:53, 18 January 2023 (UTC)

Hi, please look at this previous discussion. Hope this should help.--Patafisik (WMF) (talk) 12:02, 24 January 2023 (UTC)

It looks like the answer is there. Who has the permissions to fix this for us? Jonesey95 (talk) 00:26, 29 January 2023 (UTC)

Please insert this modified code into the gadget, per the discussion linked above:

	var node = mw.util.addPortletLink(
		document.getElementById( 'p-personal-more' ) ? 'p-personal-more' : 'p-personal',
		mw.util.getUrl( null, { action: 'purge' } ),
		'',
		'utcdate'
	);

Thank you. Jonesey95 (talk) 00:28, 29 January 2023 (UTC)

You should probably post this at Project:Village pump; AFAIK very few people other than me monitor Category:Protected edit requests here on this wiki. * Pppery * _{it has begun} 00:55, 29 January 2023 (UTC)

I've just gone ahead and patched this. Jon (WMF) (talk) 16:27, 29 January 2023 (UTC)

@Jon (WMF) You should probably update the revision date on Line 8. -- Ahecht (talk) 17:02, 27 February 2023 (UTC)

@Jon (WMF) I had long been using legacy vector and started using vector-2022 just some days ago, but the experimental version looks better and works better from the perspective of accessibility. It's been almost 4 months since the patch and the console makes no "complaints", so can we remove those wgDBname conditions? I want to use the new looking on jawiki. Dragoniez (talk) 03:24, 27 May 2023 (UTC)

Patch idea

The patch that added another clock in vector-2022 seems temporary, but the same id of utcdate is assigned to two elements and this doesn't feel right. How about preparing another id of utcdate-sticky and assigning a class like utcliveclock to both elements? (diff; sorry there's a typo in "May")

Also, if we remove the wgDBname conditions and apply the outside-the-dropdown looking on all projects (Special:diff/5947664), it may be a good idea to also place the sticky clock outside the dropdown (Special:diff/5947714). Dragoniez (talk) 12:08, 28 May 2023 (UTC)

Option to hide seconds

I find the constantly-updating seconds counter to be distracting, so Special:diff/5978477 adds a window.LiveClockHideSeconds option. LFaraone (talk) 21:22, 11 June 2023 (UTC)

{{Edit request }}

Please apply the changes in the above diff to this gadget. LFaraone (talk) 20:40, 15 June 2023 (UTC)

For future reference you're more likely to get a response to this sort of thing at Project:Village pump, although this project has relatively few active interface admins and it appears none of them monitor this queue. * Pppery * _{it has begun} 19:01, 19 July 2023 (UTC)

 Done Bawolff (talk) 20:22, 21 July 2023 (UTC)

Missing a dependency

{{Edit Protected }}

This script uses optional config values, that the user may define in its personal common.js (or vector.js, etc.), namely window.LiveClockTimeZone and window.LiveClockHideSeconds.

Therefore, the script should make sure to be executed after the user's common.js. To ensure this, a dependency to 'user' has to be added. (just as a reminder, there are two places to add it: in the gadget definition, and in the main JavaScript file)

References:

• Resources.php#L73
• UserModule.php

Od1n (talk) 06:08, 25 January 2024 (UTC)

BTW another, unrelated thing: there is an occurrence of the jQuery :first selector, which is now deprecated. Therefore, the $( node ).find( 'a:first' ) should be replaced with $( node ).find( 'a' ).first()

Od1n (talk) 06:33, 25 January 2024 (UTC)

Actually, it could just use plain DOM instead of jQuery: instead of $( node ).find( 'a:first' ), use node.querySelector( 'a' ); instead of $target.text( time ); use target.innerText = time; (assuming that $target is renamed to target to reflect the fact that it’s no longer a jQuery object). —Tacsipacsi (talk) 21:56, 25 January 2024 (UTC)

Indeed, this script could quite easily be modified to not use jQuery (apart from the "dom ready" loader). But as a first step, let's make the functional changes: adding the missing dependency, and removing the deprecated jQuery selector (deprecated since version 3.4, released on 2019…). Od1n (talk) 02:28, 27 January 2024 (UTC)

 Done Both of Od1n's changes. * Pppery * _{it has begun} 03:34, 27 January 2024 (UTC)

Clock blocks user menu when Firefox zoom at 110%

Firefox browser in Win 10 Pro PC.

I couldn't figure out how to get to preferences. I had to do a Wikipedia search to get to preferences to turn off the clock. To see if that was the problem. Which it was.

User menu is blocked at 120% zoom when there is no clock.

Why doesn't the top toolbar in Wikipedia and Mediawiki.org wrap? Maybe someone can pass this on to the developers.

— Preceding unsigned comment added by Timeshifter (talk • contribs) 3:45:02‎, 23 March 2024 (UTC)

@Timeshifter The new skin was designed by Real Designers™, and Real Designers™ haaaaaate wrapping. They've carefully designed the page with content layouts for every width breakpoint, so that everything fits exactly where it's supposed to under all circumstances.

And, in fairness, that's true... until we come along and stick something into the page that messes up their carefully-planned design. Most likely the user menu was still there, but off the right edge of your screen. (Though it would probably be scrollable, at least it is in my browser when the menu gets too wide.) But I have noticed, with the new design, that there are a lot of width breakpoints where the user menu ends up off the edge of the screen, when the clock is enabled. Which is unfortunate. FeRDNYC (talk) 15:44, 13 May 2024 (UTC)

Use Intl.DateTimeFormat object instead of querying toLocaleString every second

Per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString, Every time toLocaleString is called, it has to perform a search in a big database of localization strings, which is potentially inefficient. When the method is called many times with the same arguments, it is better to create a Intl.DateTimeFormat object and use its format() method, because a DateTimeFormat object remembers the arguments passed to it and may decide to cache a slice of the database, so future format calls can search for localization strings within a more constrained context.

The current version of this gadget is creating a new Date object using toLocaleString every second. I've rewritten it at User:Ahecht/Gadget-UTCLiveClock.js so that it creates an Intl.DateTimeFormat object once on load (and once again if window.LiveClockTimeZone is changed, although I'm not completely sure that's necessary). My new version also adds the UTC (or specified timezone) date to the title so it's visible when doing a mouseover, and adds a window.LiveClockPurgeType option that can be set to forcelinkupdate or forcerecursivelinkupdate.

Any comments before I open an actual edit request? Ahecht (talk) 15:57, 6 November 2024 (UTC)