Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

« Archives, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219

AfC templates with wrong timestamp

Normally, {{AfC submission}}'s |ts= takes the form |ts=YYYYMMDDhhmmss. But I've been coming across some drafts that have the ts param in the format generated by ~~~~~ (e.g. "00:00, 1 January 1970 (UTC)"). This shouldn't be happening, and breaks the template.

Does anyone know what is causing this? I wanted to code up a bot to fix all these, but this search only turns up a few results. ~ Rusty ^meow ~ 03:48, 16 April 2025 (UTC)

You can include cases with AFC by making the regex case insensitive with i at the end.[1] I haven't worked out how it might happen. We could ask somebody who did it. @Domagoj Klarić: Do you remember how you made this edit? You may have copied code with subst from somewhere. PrimeHunter (talk) 15:34, 16 April 2025 (UTC)

@PrimeHunter: What I'm noticing is that we have two forms of this "incorrect timestamp" template: One is {{AfC submission|||ts=...}}, which renders a "submitted for review" template, but there's also {{AfC submission|d|ts=...}}, rendering a "submission declined" without a reason. ~ Rusty ^meow ~ 14:53, 17 April 2025 (UTC)

@Rusty Cat Per Wikipedia talk:WikiProject Articles for creation#Messed up templates, this seems to be caused by people getting instructions on submitting an article from ChatGPT. --Ahecht (TALK
PAGE) 20:24, 17 April 2025 (UTC)

A technical issue

I’d like to mention an issue I’ve just recently noticed. Not serious, nonetheless inaccurate.

Something seems to be amiss with the algorithm that displays the longest stretch of consecutive days of Wiki editing that we’ve done. For a long time, my count used to be 27. Now it’s 18. This means others’ counts could similarly be affected.

Augnablik (talk) 09:00, 16 April 2025 (UTC)

@Augnablik: The information icon at Special:Impact/Augnablik says: "This metric will only reflect editing streaks included in the most recent 1,000 edits." I assume your longer streak became older. PrimeHunter (talk) 10:06, 16 April 2025 (UTC)

Oh, then sorry I didn’t notice. But I’m surprised. Not that I really care about this, but it does seem a little odd that the clock is started every X number of days.

I have one more clock-related technical issue to report: there’s a place where the number of years we’ve been Wikipedians is shown, and my count has appeared as 3 years for several months now — even though that won’t actually be till the 2nd or 3rd week of June. Augnablik (talk) 10:40, 16 April 2025 (UTC)

@Augnablik: I think the impact data makes a search for the longest streak each time it's viewed and the limit is for performance reasons. Where do you see 3 years? Special:CentralAuth/Augnablik says 2 years. PrimeHunter (talk) 11:01, 16 April 2025 (UTC)

I don't think the number that's shown in regard to my 2nd question has anything to do with performance but just time as a Wiki editor. To answer your question about where I've seen 3 years, I don't recall now exactly where that was ... all that I recall is that it's fairly often. The next time I see it, I can return here and say. Or perhaps another editor will come along and say where that is. Augnablik (talk) 11:39, 16 April 2025 (UTC)

The mobile version of your user page says "Joined 3 years ago": [2]. Matma Rex talk 20:39, 16 April 2025 (UTC)

User:Fsalas87 currently says "Joined 2 years ago" (created 17 October 2022). User:PoDawg42 says 3 years (created 16 October 2022). So the feature rounds to the nearest integer. I think that's OK with the given formulation. It would be different to say an account is 3 years old if it's only 2.5. PrimeHunter (talk) 21:26, 16 April 2025 (UTC)

But PrimeHunter, my account did consistently show me as being 3 years with Wikipedia when it was only 2.5 years — last fall. And now that there are discrepancies between what several different editors see, this makes it more likely that there are bugs in the calculation.

At any rate, I don't think rounding is a good idea for reporting our "Wiki age." Aside from simple accuracy, another reason is that those of you senior editors who help newer editors might at times want to get a clearer idea of the time we've been involved with Wikipedia, irrespective of # of our contributions. Augnablik (talk) 04:25, 17 April 2025 (UTC)

@Augnablik: Your account became 2.5 years old on 15 December 2024. I doubt it rounded to 3 before that. Rounding#Rounding to the nearest integer is a very common rounding method. It's rarely used when we say how old a person is but "Joined 3 years ago" doesn't say "old" or "age", and it doesn't describe a person but an event. I think rounding to nearest integer is OK there. Initially your mobile user page [3] actually says "Joined 15 June 2022" but it's changed by JavaScript after page load. I guess the script makes its own calculation and doesn't look up the number somewhere. It also runs in safemode [4] and at other wikis so a requested change should be at phab: (see WP:PHAB). It could point out that Special:CentralAuth/Augnablik rounds down to 2. I'm OK with either rounding method but they should probably use the same method although I wouldn't call it a bug. The mobile message is made with MediaWiki:Mobile-frontend-joined-years but it's called with 3 for you [5] and not a date or decimal age so we cannot change it locally. PrimeHunter (talk) 10:05, 17 April 2025 (UTC)

I have created phab:T392208: "Mobile user page should round down account age like CentralAuth". PrimeHunter (talk) 10:40, 17 April 2025 (UTC)

Thank you for that fix, PrimeHunter. I guess I can go on living without the other fix that I was hoping for, as there are other things in the world in greater need of fixing.

As for my recollection of what was shown as my account age some months ago, I can only say that’s what I recall. Memory can, of course, play tricks on us, and I can’t claim infallibility. Now that I’m aware that after 6 months that number will be rounded up 😢, I’ll re-check. Augnablik (talk) 13:10, 17 April 2025 (UTC)

Automating argument between template and module, and finding out template name

Hi everyone,

Two questions into one today. Here is my situation.

• I have a module that I can call with {{#invoke:module_name|main|arg1|arg2}} with arg1 being either foo or bar; and
• I want to have two templates calling this module, where:
  • {{template foo|arg}} calls {{#invoke:module_name|main|foo|arg}}, and
  • {{template bar|arg}} calls {{#invoke:module_name|main|bar|arg}}.

So the idea is that each template implicitly provides the module with arg1 without the user having to write it. How do I do that?

Secondly, when I am using the module's functions, what is an easy to get the name of the module that called it? I would use this for error messages.

Thanks! Julius Schwarz (talk) 09:46, 16 April 2025 (UTC)

If I understand what it is that you want to do, you can hard-code foo and bar in the template wikitext as named parameters: |foo=<value> etc – this is probably the simplest. No doubt there are more complex ways to do what I think you want to do.

To get the name of the invoking module: frame:getTitle(); and similarly, to get the name of the calling template: frame:getParent():getTitle().

—Trappist the monk (talk) 13:21, 16 April 2025 (UTC)

As TtM said, {{#invoke:module_name|main|foo| {{{arg|}}} }} should work.

If {{{arg}}} is a number of arguments, you can also make use of one or both of the following two tables (mw:Extension:Scribunto/Lua_reference_manual#frame.args):

• local targs = frame:getParent().args --template arguments in template call
• local margs = frame.args --module arguments in #invoke

Ponor (talk) 14:03, 16 April 2025 (UTC)

Thank you @Trappist the monk and @Ponor for your help. TtM knows it takes me a bit to get these things :) I have tried and it is not yet working. Here is the template and here is what it gives.. :S Julius Schwarz (talk) 07:28, 17 April 2025 (UTC)

@Julius Schwarz: check this. Ponor (talk) 07:37, 17 April 2025 (UTC)

Like magic!! thank you so much! And, if I got this right, we only need to do the {{}} for unnamed arguments, right? Julius Schwarz (talk) 07:41, 17 April 2025 (UTC)

I am not familiar with the module itself. But if there are named params, I'd assume you need to add translations like namedOne={{{namedOne|}}} to the template's code, for all the named ones you need. Make a test case and I'll show you, if needed. Ponor (talk) 08:16, 17 April 2025 (UTC)

Just saw your second test case. The module seems smart enough (by calling another module) to get the named params without any mapping. You're good to go! Ponor (talk) 08:34, 17 April 2025 (UTC)

Yes it seems all in order and the examples are working great. Thank you so much! Julius Schwarz (talk) 09:16, 17 April 2025 (UTC)

@Julius Schwarz If it were me, I would just make it so {{template foo|arg}} calls {{#invoke:module_name|foo|arg}} and {{template bar|arg}} calls {{#invoke:module_name|bar|arg}}. p.foo(frame) and p.bar(frame) can just be wrappers that call p.main(type, frame). --Ahecht (TALK
PAGE) 20:22, 17 April 2025 (UTC)

Technical concern about wikis using Wikipedia content.

Where can we report suspicious activity in terms of site using Wikipedia content? There is one site that may be a cybersecurity risk for unsuspecting users. Starlighsky (talk) 22:38, 16 April 2025 (UTC)

@Starlighsky Use of Wikipedia trademarks to mislead should be reported to the WMF legal team at legal-tm-viowikimedia.org. Security issues relating to MediaWiki or Wikimedia Foundation infrastructure should be reported to securitywikimedia.org or by using this Phabricator form. General threats to the safety of contributors can be reported to the WMF Trust and Safety team at cawikimedia.org. If you're unsure, feel free to email me and I can help route your concerns. AntiCompositeNumber (talk) 23:59, 16 April 2025 (UTC)

@Starlighsky: Is this a case of reusing our content without attribution? See Wikipedia:Reusing Wikipedia content and wmf:Wikimedia Foundation Terms of Use. --Redrose64 🌹 (talk) 12:46, 17 April 2025 (UTC)

The site is in another language, and I don't know if they are or are not. I want to avoid the site due to the cybersecurity issues that I suspect are on the site. I emailed the issue and the language that the site was written in. Ideally, there is a cybersecurity professional who can look at the site. I discovered the site after a search for a specific topic. I recognized the content as a Wikipedia article, which I can explain later if needed. The site does see it is not affiliated with Wikimedia. That is all I know. Starlighsky (talk) 13:02, 17 April 2025 (UTC)

Quarry queries don't run

Tracked in Phabricator
Task T392107

Hi, when I try to run my queries on https://quarry.wmcloud.org/, I get a pop-up message that is very long (which for some reason I can't copy) and eventually a message that states

Error

This web service cannot be reached. Please contact a maintainer of this project.

Maintainers can find troubleshooting instructions from our documentation on Wikitech.

I filed a bug report but I was hoping another editor might have more familiarity with Phab and filing tickets. Liz ^{Read! Talk!} 00:10, 17 April 2025 (UTC)

It looks like this problem might be resolved. But I'll leave it here as a report. Liz ^{Read! Talk!} 01:09, 17 April 2025 (UTC)

Why are infobox image sizes huge now?

See Mario Vargas Llosa and Margaret Thatcher, for example. This really isn't an improvement. ‑‑Neveselbert (talk · contribs · email) 01:30, 17 April 2025 (UTC)

See the weekly highlight above in § Tech News: 2025-16 jlwoodwa (talk) 01:35, 17 April 2025 (UTC)

This is clearly a bug. This change should only affect thumbnails, not infobox images. ‑‑Neveselbert (talk · contribs · email) 01:36, 17 April 2025 (UTC)

I thought it was for all images. We were having trouble with some images loading because of issues with the thumbnails. The image has to be resized to fit in the infobox. Hawkeye7 (discuss) 02:02, 17 April 2025 (UTC)

There was no consensus here to increase the default size for all images, only for thumbnails. ‑‑Neveselbert (talk · contribs · email) 02:13, 17 April 2025 (UTC)

The templates should be updated then, they just follow the default setting. Sjoerd de Bruin (talk) 08:32, 17 April 2025 (UTC)

For Vargas Llosa, if I am reading the template code at {{infobox writer}} correctly, the image is being assigned the default size of frameless, which renders the image at the default thumbnail size width. That width was just increased from 220px to 250px, per the tech note above, after that change had been requested for many years. I see the image rendering at 250px, which means that things are working as designed. (Here are archive.org snapshots of the pages yesterday, 220px image and today, 250px image.) If you are seeing something that does not appear to be working as designed, please describe it here. – Jonesey95 (talk) 14:52, 17 April 2025 (UTC)

Also, the RFC from January 2024, linked to above, says This bifurcated discussion finds a strong consensus to increase the default thumbnail size on English Wikipedia to 250px. – Jonesey95 (talk) 14:59, 17 April 2025 (UTC)

Infobox images are not thumbnails though. They use frameless, not thumb. ‑‑Neveselbert (talk · contribs · email) 19:16, 19 April 2025 (UTC)

@Neveselbert: Yes, but as noted elsewhere in this section (twice), the width used for |frameless is the same as the width used for |thumb. See demo at Wikipedia:Sandbox, preferably when logged out. --Redrose64 🌹 (talk) 20:42, 19 April 2025 (UTC)

In which case, the width used for frameless should be restored to 220px pending consensus. ‑‑Neveselbert (talk · contribs · email) 21:55, 19 April 2025 (UTC)

@Neveselbert: They're not independent settings, and AFAIK, never have been. A configuration change for |thumb has been carried out (on 17 April), as a consequence of which the with for |frameless necessarily had to follow suit. If you want them to be divorced, you need to file a ticket at phab:. --Redrose64 🌹 (talk) 23:47, 19 April 2025 (UTC)

Infobox images are thumbnails, are they not? I had my thumbnail size set to 300px in Special:Preferences#mw-prefsection-rendering-files for years, and it always affected infoboxes too. Matma Rex talk 21:12, 17 April 2025 (UTC)

Some are set to use frameless and some are set to fixed pixel sizes. Some other common infobox graphics, like maps, can't be set to use the reader's thumbnail size preference, so some editors have chosen to use fixed sizes for images to match the width of maps. – Jonesey95 (talk) 23:02, 17 April 2025 (UTC)

It is even less of an improvement in the case of non-free images like film posters, which are compressed and consequently lack the clarity and detail necessary for comfortable viewing at this higher resolution. Οἶδα (talk) 09:55, 17 April 2025 (UTC)

Please link to an example article. Maybe we need to adjust our maximum acceptable size for non-free images. That would be a discussion for a different page. – Jonesey95 (talk) 14:52, 17 April 2025 (UTC)

Honestly, most of them. Though many are worse than others. I realise this is an issue with the files themself but it remains that this change renders these posters looking worse. Comparing png files like the ones at Boyhood (2014 film), Drugstore Cowboy or Good Will Hunting, which are far crisper, or high-res Commons photos like the ones appearing at M*A*S*H (film) or Seven Samurai, to the jpg at Short Cuts, you should see what I mean. Viewing that thumbnail at the original resolution looks better to my eyes. To a lesser extent, the one at Pulp Fiction. Must it be expanded to fill the infobox? Of course this is my opinion and I am not suggesting any actions. But 250px looks worse to my eyes for most posters. Οἶδα (talk) 22:04, 17 April 2025 (UTC)

I remember predicting this exact situation when the non-free content policy, limiting the size, was made. —TheDJ (talk • contribs) 22:48, 17 April 2025 (UTC)

The Short Cuts poster is 19KB and looks like it has been over-compressed. The previous infobox default was reducing it from 255px to 220px wide, and now it is being reduced to 250px, which highlights the over-compression. Someone needs to upload a better-quality image. The Good Will Hunting image is the same pixel size but is 231KB. That's probably why it looks better. – Jonesey95 (talk) 23:02, 17 April 2025 (UTC)

@Jonesey95 Film posters should be resized to 0.1 megapixels, which, for a standard 3:2 poster, means 258x387 (although they generally range from 254x393 to 260x384). We don't need to update the maximum size, but rather set the resizing bot to prefer a width of 250px if the final image is going to be close to that value to avoid unnecessary rescaling. --Ahecht (TALK
PAGE) 20:38, 17 April 2025 (UTC)

It depends upon the infobox. Some are coded to use a specific size; others are coded for the frameless type, which should read the user's preferences. No infobox should be coded to use the thumb type, because of the extra borders that produces. --Redrose64 🌹 (talk) 21:35, 17 April 2025 (UTC)

BTW, i’ve been running with a default of 300px for years now, which is even bigger. —TheDJ (talk • contribs) 22:53, 17 April 2025 (UTC)

I have the time enabled in preferences - should show UTC +1 for DST but doesn't

Can I fix this? Doug Weller talk 16:21, 19 April 2025 (UTC)

where are you not seeing it? Contributions, watchlist or somewhere else? Nthep (talk) 16:43, 19 April 2025 (UTC)

I see the time, it’s in the upper right corner. But it is in UTC, amd should be one hour forward for Daylight Saving Time. It shows 17:16 instead of 18:16 Doug Weller talk 17:17, 19 April 2025 (UTC)

My watchlist is ok, but I sign as though it’s only 17 :17 Doug Weller talk 17:18, 19 April 2025 (UTC)

UTC has no concept of daylight saving time. --Redrose64 🌹 (talk) 18:12, 19 April 2025 (UTC)

@Doug Weller: If you see time in the upper right corner then you probably enabled "Add a clock to the personal toolbar that displays the current time in UTC" at Special:Preferences#mw-prefsection-gadgets. It's meant to be UTC as it says. Signatures are saved as wikitext in UTC but you can enable "Change UTC-based times and dates, such as those used in signatures, to be relative to local time" at Special:Preferences#mw-prefsection-gadgets. The timezone preference at Special:Preferences#mw-prefsection-rendering is only for time logs like in the watchlist, page histories and user contributions. PrimeHunter (talk) 18:18, 19 April 2025 (UTC)

@Doug Weller: If it's the clock then add window.LiveClockTimeZone = 'Europe/London'; //LiveClock timezone settings to your common.js page. That should make it display BST for you now and it will autocorrect when the clocks go back. Nthep (talk) 18:33, 19 April 2025 (UTC)

Thanks, fixed now. Doug Weller talk 08:38, 20 April 2025 (UTC)

Frooti page infobox parts not working

Headquarters and countries served are in the code of the infobox but aren't showing please fix this Depotadore (talk) 17:01, 19 April 2025 (UTC)

Infobox parameters have to be implemented in the used infobox template. Frooti uses Template:Infobox Beverage which has no such parameters so they are ignored. See the template page for supported parameters. PrimeHunter (talk) 18:24, 19 April 2025 (UTC)

Thanks now im gonna fix it Depotadore (talk) 02:47, 20 April 2025 (UTC)

Gadget to hide decorative sticky elements

Per Special:GoToComment/c-AntiCompositeNumber-20250420003300-RfC:_allowing_editors_to_opt-out_of_seeing_floating_decorative_elements, we should have a gadget labeled "Hide decorative sticky elements" that consists of the following CSS file:

.sticky-decoration {display:none !important;}

Aaron Liu (talk) 01:49, 20 April 2025 (UTC)

I had made a thingy at User:HouseBlaster/sandbox.css. I propose and support simply making that into a gadget. Best, HouseBlaster (talk • he/they) 02:01, 20 April 2025 (UTC)

For reference, the line of CSS I gave is the same exact thing but with 200% the spaces. Though, I also just changed my line of CSS to say "sticky-decoration" instead of "floating-decoration". Aaron Liu (talk) 04:19, 20 April 2025 (UTC)

There was no opposition to the suggestions of creating a gadget to opt-out and for other editors to edit user pages to implement the class, but these issues did not have significant discussion. does not support the creation of a gadget, so I suppose you're taking up the suggestion? A one liner isn't really what we should support gadgets for, and it really is a one liner. Izno (talk) 04:36, 20 April 2025 (UTC)

Normally I would agree with you. I think that telling people, in an official guideline, to go and check a box in their preferences is far superior to telling them to fiddle with their CSS. Best, HouseBlaster (talk • he/they) 04:40, 20 April 2025 (UTC)

I agree, especially since this is a matter of accessibility. jlwoodwa (talk) 07:21, 20 April 2025 (UTC)

Just curious, but the RfC was about user pages, but are there any legitimate uses of these "position: <absolute|sticky|fixed>;" elements elsewhere? I know I have been meaning to get the up/down skip buttons used on WP:HD and WP:TEA adjusted so they don't obscure the mobile/desktop toggle. Commander Keane (talk) 07:31, 20 April 2025 (UTC)

The skip buttons you mention were brought up in the RfC statement as one example of legitimate use. Aaron Liu (talk) 14:46, 20 April 2025 (UTC)

Support making that into a gadget as well. * Pppery * _{it has begun...} 13:46, 20 April 2025 (UTC)

Support, I guess. Though, this seems like a fool's errand, as editors can and will create new elements regularly, and these won't be with the class sticky-decoration (or whatever class name), so the gadget will do nothing. Gonnym (talk) 13:55, 20 April 2025 (UTC)

The new section (WP:DecoFloat) created by that RfC which thus is now a guideline says that such new elements should have that class, and another thing unopposed (though not really discussed) in the RfC is that editors should be able to drive by and add the class. I'm sure opt-outers would gnome every example of such stickies. Aaron Liu (talk) 14:46, 20 April 2025 (UTC)

That's all fine. As an editor who fixes lint and other errors, I doubt most people that add those annoying features are going to add the class, which then falls upon gnomes and other editors to fix those horrible features. So we require at least two steps for editors to not view these, and yet still non-registered users can't hide them. Gonnym (talk) 14:49, 20 April 2025 (UTC)

I feel like most of this was already discussed in the RfC. There's no independent merits you've brought up that only apply to the gadget proposal and not the RfC. Aaron Liu (talk) 15:01, 20 April 2025 (UTC)

Well then, you know what. I completely oppose on the ground that I think this will do nothing and is completely pointless. Hope that helps. Gonnym (talk) 18:29, 20 April 2025 (UTC)

If the usage on user pages is deemed a significant accessibility issue, then personally I think the elements in question should be hidden by default, and users can opt into seeing them. If there isn't enough usage to make it a significant accessibility issue, then I think the drawback of adding an additional gadget isn't warranted. isaacl (talk) 16:58, 20 April 2025 (UTC)

Don't let the perfect be the enemy of the good. jlwoodwa (talk) 17:12, 20 April 2025 (UTC)

Managing accessibility concerns is about managing tradeoffs. Neither approach is perfect. In my opinion, if the accessibility issue is significant, then the better tradeoff is to let people opt into the problem, rather than opt out of it. isaacl (talk) 18:00, 20 April 2025 (UTC)

It's only a significant issue for a significant but small percentage of users; I think it's worth the drawback (I presume you just mean the preferences table and the in-this-case-tiny burden on intadmins). The significant drawbacks of having such elements be hidden by default have been discussed in the RfC. Aaron Liu (talk) 17:57, 20 April 2025 (UTC)

Conditional highlighting in a table

This clever edit causes the most relevant line to be highlighted, e.g., in Butter#Nutritional information. However, in Shortening, to which Vegetable shortening redirects, the relevant line is not highlighted, because it's not at the "Vegetable shortening" page (not all shortenings are vegetable shortenings, but most of them are). Could someone please hard-code the page name "Shortening" into this template? WhatamIdoing (talk) 02:15, 20 April 2025 (UTC)

@WhatamIdoing:  Done All that was needed was this edit. --Redrose64 🌹 (talk) 08:06, 20 April 2025 (UTC)

Eileen Kelly title italicised

The title for Eileen Kelly appears to be automatically italicised for me on my mobile device; this seems to have happened when the podcast infobox was added to the article. Can anyone help? GnocchiFan (talk) 13:12, 20 April 2025 (UTC)

The problem was that the podcast infobox ({{Infobox podcast}}) automatically italicizes the article’s title (since it assumes it’s on the article of a podcast). I’ve fixed this by adding | italic title = no to the template.

Hope this helps!
— Daℤyzzos (✉️ • 📤) _{Please do not ping on reply.} 13:45, 20 April 2025 (UTC)

The problem is having an infobox at the top of the page for a sub section two-sentence long. Gonnym (talk) 18:26, 20 April 2025 (UTC)

Layout screwed up

I have no idea how to fix this. Have tried muzzalaynees thangs, no go. SergeWoodzing (talk) 17:17, 20 April 2025 (UTC)

If you go to the "View history" page, you can see a list of the edits. Click on the previous version in the left column of dots and the latest version in the right column of dots, then click "Compare selected versions". From that screen, you can see the changes that you made and click the "undo" link to restore the previous version. I did it for you this time. – Jonesey95 (talk) 17:35, 20 April 2025 (UTC)

The previous was even worse. SergeWoodzing (talk) 18:08, 20 April 2025 (UTC)