moment-timezone doesn't seem to be in use:

• only core/resources/lib/moment, but no moment-timezone is present
• no results for .tz referring to moment via codesearch (referring to the tz function of https://momentjs.com/timezone/)

In the meanwhile I18n has landed in dayjs, see https://github.com/iamkun/dayjs/blob/dev/docs/en/I18n.md

For simple formatting, the JavaScript [Date.toLocaleString](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString) might be sufficient (providing good browser support for its basic usage).

One question is also how strict the localized output must be, e.g., I'm relating to the en locale override in core/resources/src/moment/moment-dmy.js.

In core we have a few calls to moment() (codesearch), in MobileFrontend only two (codesearch)

Would it make sense to submit a patch replacing the moment usage in an extension such as MobileFrontend or MultimediaViewer as a starting point?

Quoting https://momentjs.com/docs/#/-project-status/ :

we would like to discourage Moment from being used in new projects going forward. Instead, we would like to recommend alternatives that are excellent choices for use in modern applications today

We could evaluate using Intl, not sure if it covers all of moment's timezone use cases but probably enough for simple date formatting. GrowthExperiments and other extensions are already using it. Probably some old browser compatibility would be desired, a partial polyfill maybe.

I suggested MediaWiki date formatter keywords to Moment.js in 2014 https://github.com/moment/moment/issues/1454 due to localization needs in moment.js to fully support MediaWiki and it was closed years later referring to the page also linked above, "We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done.", so guess the correct direction here would be first deprecate moment.js module then try to reduce the uses till the removal as it doesn't support needed localization stuff (non-Gregorian calendars) which browser-own Intl does support for free.

Change #1062961 had a related patch set uploaded (by Ebrahim; author: Ebrahim):

[mediawiki/core@master] Declare moment.js dependency deprecated

https://gerrit.wikimedia.org/r/1062961

Change #1062961 abandoned by Ebrahim:

[mediawiki/core@master] Declare moment.js dependency deprecated

https://gerrit.wikimedia.org/r/1062961

@Ebrahim https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend#Deprecation_process documents the deprecation process in case that's helpful.

with something smaller (what?)

For personal as well as professional projects, I've started using dayjs which amounts to 3kB gzipped (https://bundlephobia.com/package/dayjs@1.11.12). – https://day.js.org/

See also: https://npmtrends.com/date-fns-vs-dayjs-vs-moment

Change #1063341 had a related patch set uploaded (by Ebrahim; author: Ebrahim):

[mediawiki/core@master] Remove use of moment.js in Special:EditRecovery

https://gerrit.wikimedia.org/r/1063341

Change #1063341 merged by jenkins-bot:

[mediawiki/core@master] Remove use of moment.js in Special:EditRecovery

https://gerrit.wikimedia.org/r/1063341

JavaScript Temporal is coming | MDN Blog – shipping with Firefox 139 – Temporal - JavaScript | MDN

I think at this point we should mark moment in core as deprecated per https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend#Guidelines_for_providers_removing_ResourceLoader_modules and point to mediawiki.DateFormatter

In T146798#10760033, @Jdlrobson-WMF wrote:

I think at this point we should mark moment in core as deprecated per https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend#Guidelines_for_providers_removing_ResourceLoader_modules and point to mediawiki.DateFormatter

Agreed. The first step would be announcing the replacement to people who aren't CC'ed on this task. Maybe add something to Tech/News?

Change #1138412 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Deprecate moment library

https://gerrit.wikimedia.org/r/1138412

Once above patch is merged, I'll put a notice in tech news.

Developers MAY fix consumers of a module prior to deprecation, but doing so is not required as a precursor to deprecation.

I reviewed https://codesearch.wmcloud.org/deployed/?q=%22moment%22&files=%28extension%7Cskin%29%5C.json&excludeFiles=&repos= and none of these are loaded on article page load (only special pages and diff pages), so there will be little spam outside gadgets in developer console.

global search has a few more uses that may cause spam outside dev console.

In T146798#10761989, @Izno wrote:

global search has a few more uses that may cause spam outside dev console.

That's fine. I think the main worries would be default ones that load for anonymous users (but I'd hope nobody is loading the moment library on a default gadget as that would be a performance issue and worth the log spam).

Change #1138412 merged by jenkins-bot:

[mediawiki/core@master] Resources: Mark moment library as deprecated

https://gerrit.wikimedia.org/r/1138412

Change #1139100 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/core@master] BookletLayout: remove moment dependency

https://gerrit.wikimedia.org/r/1139100

Change #1139100 merged by jenkins-bot:

[mediawiki/core@master] BookletLayout: remove moment dependency

https://gerrit.wikimedia.org/r/1139100

Change #1149427 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/extensions/VisualEditor@master] Remove moment library and no longer display upload date as relative time

https://gerrit.wikimedia.org/r/1149427

Change #1149430 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/extensions/VisualData@master] fileUploadProgress event: remove unused estimatedRemainingTime

https://gerrit.wikimedia.org/r/1149430

Change #1149431 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/core@master] fileUploadProgress event: remove unused estimatedRemainingTime

https://gerrit.wikimedia.org/r/1149431

Change #1149431 merged by jenkins-bot:

[mediawiki/core@master] fileUploadProgress event: remove unused estimatedRemainingTime

https://gerrit.wikimedia.org/r/1149431

Change #1149478 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/extensions/RevisionSlider@master] Replace moment with DateFormatter.formatTimeAndDate

https://gerrit.wikimedia.org/r/1149478

Change #1149480 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/extensions/MediaUploader@master] Replace moment with DateFormatter.formatTimeAgo

https://gerrit.wikimedia.org/r/1149480

Change #1149478 merged by jenkins-bot:

[mediawiki/extensions/RevisionSlider@master] Replace moment with DateFormatter.formatTimeAndDate

https://gerrit.wikimedia.org/r/1149478

Change #1149440 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/core@master] DateFormatter.formatRelativeTimeOrDate using Intl.RelativeTimeFormat

https://gerrit.wikimedia.org/r/1149440

Change #1152434 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/extensions/PageTriage@master] Replace moment with mediawiki.DateFormatter

https://gerrit.wikimedia.org/r/1152434

Change #1149440 merged by jenkins-bot:

[mediawiki/core@master] DateFormatter.formatRelativeTimeOrDate using Intl.RelativeTimeFormat

https://gerrit.wikimedia.org/r/1149440

Is there a way to use mediawiki.DateFormatter with a browser native timezone rather than UTC, the site timezone, or user preference timezone? I would like to convert my https://meta.wikimedia.org/wiki/User:BDavis_(WMF)/Scripts/zonestamp-moment.js userscript that formats https://meta.wikimedia.org/wiki/Template:Zonestamp output as "local time", but I can't figure out how to construct a mediawiki.DateFormatter instance in the browser native timezone.

I'm probably a weird user in that I like seeing most timestamps in UTC for easier cross-platform comparison, but when I'm looking at something like a conference schedule I would rather see local time timestamps that follow my device config.

Change #1166939 had a related patch set uploaded (by Gerrit Patch Uploader; author: Anne Haunime):

[mediawiki/core@master] Make use of ES2017's padStart()

https://gerrit.wikimedia.org/r/1166939

Change #1166939 merged by jenkins-bot:

[mediawiki/core@master] ForeignStructuredUpload: Make use of ES2017's padStart()

https://gerrit.wikimedia.org/r/1166939

Change #1149430 abandoned by Simon04:

[mediawiki/extensions/VisualData@master] fileUploadProgress event: remove unused estimatedRemainingTime

https://gerrit.wikimedia.org/r/1149430

Change #1152434 abandoned by Simon04:

[mediawiki/extensions/PageTriage@master] Replace moment with mediawiki.DateFormatter

https://gerrit.wikimedia.org/r/1152434

Change #1149480 abandoned by Simon04:

[mediawiki/extensions/MediaUploader@master] Replace moment with DateFormatter.formatRelativeTimeOrDate

https://gerrit.wikimedia.org/r/1149480

Change #1149427 abandoned by Simon04:

[mediawiki/extensions/VisualEditor@master] Remove moment library and no longer display upload date as relative time

https://gerrit.wikimedia.org/r/1149427

In T410135#11376100, @Krinkle wrote:

In T410135 @Back_ache wrote

[…] according to the message will mean that soon part of the functionality might not work at all

This warning comes from our own software […] to communicate between MediaWiki core developers and third-party extension developers, or between MediaWiki developers and gadget authors, to let them know they are relying on a feature that will soon be removed […].

Unfortunately, the hard-deprecation warning for "moment" was added at a time when this feature is still used inside MediaWiki core and by WMF-maintained code. This is contrary to our stable interface policy where it says "Hard deprecation must be applied this to code still used in Wikimedia maintained code. Such usage must be removed first."

Sorry for the confusion. MediaWiki will of course migrate these two features before removing "moment". We will not break our own edit software!

I suggest that in the future, the person doing the hard deprecation first commits to upgrading callers themselves and/or has commitment from affected WMF teams before doing so.

In its current form it is a distraction to every person opening the browser console, watering down other more important signals, with noise that isn't intended for them.

I suggest that in the future, the person doing the hard deprecation first commits to upgrading callers themselves and/or has commitment from affected WMF teams before doing so.

@Back_ache that policy only applies to PHP code. For frontend code, it's advised but not a requirement. That's because when drafting the frontend stable interface policy (https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend#Guidelines_for_providers_removing_ResourceLoader_modules) I got some feedback from against this, so it got reduced to "MAY".

Moment was deprecated on April 2025 in c85c649a7566. At the time it was not being used on page load for anonymous article views. It still isn't being used for anonymous views as far as I can see so this only impacted logged in users.

In its current form it is a distraction to every person opening the browser console, watering down other more important signals, with noise that isn't intended for them.

Sure, but we have a problem with default gadgets using deprecated library and one of the few ways we have to communicate with them (for non English languages in particular) is through the developer console. The fact this discussion showed up here shows that they get noticed. The majority of people doing deprecations are not comfortable fixing gadgets and I don't think they should be blocked handling deprecations. I have been working with Wikivoyage communities to get rid of jquery.ui for over a year for example.

A nice compromise would be to change the requirement from MAY to MUST for certain modules but we'd need to discuss what those would be. It seems reasonable to require it for logged out users but logged in users (and their gadgets) seems a little unreasonable to me. Some deprecations are not trivial and would never happen if we enforced that requirement. Part of deprecation is also ensuring new clients don't adopt code. Perhaps we need some notion of soft and hard deprecation in ResourceLoader to assist with that (so we can at least only log warnings in developer environments for soft deprecations)?

Happy 2026! Temporal is natively supported by Chrome 144+, Edge 144+, Firefox 139+, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal#browser_compatibility

The Temporal features the following distinct time-related objects: Duration, Instant, PlainDate, PlainDateTime, PlainMonthDay, PlainTime, PlainYearMonth, ZonedDateTime. Formatting is provided by Intl.DateTimeFormat. However, no parsing/formatting based on a provided pattern (such as "dd.mm.YYYY") is provided by this API.