Moment.js News

It has been almost six years since we last wrote about the status of Moment.js. That is a long time on the web, and the way software is written has changed in ways we did not anticipate in 2020.

The most significant change is the arrival of AI-assisted and agentic software development. Moment appears throughout the code, documentation, tutorials, and questions on which coding agents learned. It is familiar to those systems, just as it is familiar to generations of JavaScript developers. Agents now select Moment, add it to projects, write code with it, and encounter it in existing dependency trees, often without a person making a deliberate library choice.

Weekly downloads have more than tripled since our previous update. Download counts have never been a precise measure of people or projects, and automated workflows make them even less so. Still, we believe most of this new growth is connected to agentic use, and the code being produced is real code that people will need to run and maintain.

This has caused us to reconsider how we talk about Moment's long-term maintenance. The spirit of our 2020 message has not changed: Moment is a legacy project, and stability for existing users matters more than expanding its scope. But we were shortsighted to say that there would never be a version 3, or to rule out entire categories of technical work forever.

What maintenance mode means

We are not accepting new user-facing features or capabilities. We also are not redesigning Moment's mutable API or changing established behavior simply to align it with newer API conventions. For the millions of projects that already rely on Moment, predictability remains one of its most important features.

That does not mean every valid bug report will result in a change. Sometimes a behavioral quirk has itself become part of what applications rely on. We will weigh severity and expected benefit against compatibility risk, established behavior, and the time available from volunteer maintainers. In some cases, the most responsible maintenance decision will be to leave existing behavior alone.

It also does not mean the project must remain technically frozen. Maintainers may undertake work on Moment's implementation, packaging, TypeScript declarations, build and release tooling, bundle composition, or runtime support. That work will be planned and initiated by the maintainers so that it can be considered as a whole rather than arriving as disconnected modernization proposals.

Upcoming releases and version 3

We expect to publish some Moment 2.x maintenance updates soon. These will focus on changes that can be delivered without breaking the compatibility promises of the 2.x line.

There is also a class of bugs and technical maintenance tasks that we cannot fix correctly in a 2.x release. Correcting them may change documented APIs, long-established output, packaging behavior, or another contract covered by semantic versioning. Even when the goal is maintenance, those changes require a major version number.

For that reason, maintenance mode no longer categorically rules out Moment 3.0. A 3.0 release would not restart feature development or turn Moment into a new library. It would still be a maintenance release, using a major version where semver requires us to acknowledge breaking changes honestly. We do not have a Moment 3.0 schedule to announce today.

Locale updates

Locale data has always depended on balancing published standards with the real conventions of the people and cultures represented. Our preferred baseline is the latest published Unicode CLDR data, but CLDR is not an absolute gate. We may use a different convention when strong, authoritative language or cultural evidence shows that CLDR is stale, inaccurate, or does not reflect documented usage.

We ask contributors to include supporting sources when they can, but sources are not a requirement. Maintainers will independently validate proposed behavior. If a proposal revisits a previous discussion or decision, please explain what new context or evidence supports reconsidering it.

Security and time zone data

Please submit security reports privately through the Moment repository's security page. We will acknowledge and assess every report, and we will address critical security concerns that affect Moment.js. Depending on severity, impact, practical mitigations, compatibility risk, and maintainer capacity, other reports may result in a fix, mitigation, documentation, or no code change.

Moment Timezone data updates will continue to follow IANA time zone database releases.

Moment is maintained by volunteers, so priorities and response times will continue to depend on available capacity. We are grateful to everyone who has used, supported, and contributed to the project over the years, and to everyone helping us care for the software that still depends on it.

This article was published September 14, 2020 and has been superseded by the August 17, 2026 Project Status update.

Moment.js has been successfully used in millions of projects, and we are happy to have contributed to making date and time better on the web. As of September 2020, Moment gets over 12 million downloads per week! However, Moment was built for the previous era of the JavaScript ecosystem. The modern web looks much different these days. Moment has evolved somewhat over the years, but it has essentially the same design as it did when it was created in 2011. Given how many projects depend on it, we choose to prioritize stability over new features.

As an example, consider that Moment objects are mutable. This is a common source of complaints about Moment. We address it in our usage guidance but it still comes as a surprise to most new users. Changing Moment to be immutable would be a breaking change for every one of the projects that use it. Creating a "Moment v3" that was immutable would be a tremendous undertaking and would make Moment a different library entirely. Since this has already been accomplished in other libraries, we feel that it is more important to retain the mutable API.

Another common argument against using Moment in modern applications is its size. Moment doesn't work well with modern "tree shaking" algorithms, so it tends to increase the size of web application bundles. If one needs internationalization or time zone support, Moment can get quite large. Modern web browsers (and Node.js) expose internationalization and time zone support via the Intl object, codified as ECMA-402. Libraries like Luxon (and others) take advantage of this, reducing or removing the need to ship your own data files.

Recently, Chrome Dev Tools started showing recommendations for replacing Moment for the size alone. We generally support this move.

You may also want to read:

• You Probably Don't Need Moment.js Anymore
• You don't (may not) need Moment.js
• Why you shouldn't use Moment.js...
• 4 alternatives to moment.js for internationalizing dates

The Moment team has discussed these issues at length. We recognize that many existing projects may continue to use Moment, but 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 would also like to promote the Temporal addition to the JavaScript language, which is looking for feedback and contributors.

We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done.

In practice, this means:

• We will not be adding new features or capabilities.
• We will not be changing Moment's API to be immutable.
• We will not be addressing tree shaking or bundle size issues.
• We will not be making any major changes (no version 3).
• We may choose to not fix bugs or behavioral quirks, especially if they are long-standing known issues.

With specific regard to Moment's internationalization locale files:

• We may choose to not accept corrections to locale strings or localized date formats, especially if they have been argued successfully for their present form.
• You must make a new compelling argument for locale changes with significant, non-anecdotal evidence to support your position.
• If the string or format you are asking to change is reflected in the CLDR, then you must submit a change there first and have it accepted.

However, since we understand that Moment is well established in millions of existing projects:

• We will address critical security concerns as they arise.
• We will release data updates for Moment-Timezone following IANA time zone database releases.

Reasons to keep using Moment

In most cases, you should not choose Moment for new projects. However there are some possible reasons you might want to keep using it.

Browser support

Moment works well on Internet Explorer 8 and higher. By contrast, Luxon only works on IE 10 and higher and requires a polyfill to do so. You can read more in Luxon's documentation.

Other libraries have also had issues with Safari, especially on mobile devices. If you have a strong requirement to support older browsers, then you might want to stick with Moment for a bit longer.

However, Day.js reports compatibility with IE8 and higher so you still may wish to consider that alternative.

Dependency by other libraries

Several other libraries, especially date pickers and graphing libraries, take Moment as a dependency. If you are using such a component and cannot find an alternative, then you are already including Moment in your project. Thus, it might make sense to continue using Moment throughout your project rather than including yet another date and time library.

Familiarity

If you are a long-time user of Moment, you may already understand its API and limitations well. If so, and the aforementioned issues are not a concern for you, then you certainly can continue to use it.