Roan suggested https://github.com/jquery/globalize might be a good replacement but may equally be large.

Based on https://github.com/jquery/globalize#pick-the-modules-you-need it sounds like it might be smaller than moment, although those figures don't include the CLDR data that you need.

@Jdlrobson @Catrope “may equally be large” vs “might be smaller than moment”?!

Another possible alternative hot off the news: https://github.com/xx45/dayjs – described as ”Fast 2KB date library alternative to Moment.js with the same modern API“

In T146798#4155920, @Volker_E wrote:

Another possible alternative hot off the news: https://github.com/xx45/dayjs – described as ”Fast 2KB date library alternative to Moment.js with the same modern API“

Unfortunately AFAICT that one is small and fast by not doing i18n, which is a non-starter for us.

I'm not familiar with all of moment.js abilities, but there's discussion for “internationalization” https://github.com/xx45/dayjs/issues/36

Hot from the press: https://github.com/you-dont-need/You-Dont-Need-Momentjs

Do we use timezone localisation? This seems to be the biggest problem with moving away...

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.