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."
Here are the alternatives we recommend:
Luxon
Luxon can be thought of as the evolution of Moment. It is authored by Isaac Cambron, a long-time contributor to Moment. Please read Why does Luxon exist? and the For Moment users pages in the Luxon documentation.
- Locales:
Intlprovided - Time Zones:
Intlprovided
Day.js
Day.js is designed to be a minimalist replacement for Moment.js, using a similar API. It is not a drop-in replacement, but if you are used to using Moment's API and want to get moving quickly, consider using Day.js.
- Locales: Custom data files that can be individually imported
- Time Zones:
Intlprovided, via a plugin
date-fns
Date-fns offers a series of functions for manipulating JavaScript Date objects. For more details, scroll to "Why date-fns?" on the date-fns home page.
- Locales: Custom data files that can be individually imported
- Time Zones:
Intlprovided, via a separate companion library
js-Joda
js-Joda is a JavaScript port of Java's Three-Ten Backport, which is the base for JSR-310 implementation of the Java SE 8 java.time package. If you are familiar with java.time, Joda-Time, or Noda Time, you will find js-Joda comparable.
- Locales: Custom data files via add-on module
- Time Zones: Custom data files via add-on module
No Library
JavaScript has always had a Date object, defined ECMAScript (ECMA-262) specification here.
When using Date objects, be aware of the following:
The
Dateobject internally represents a Unix timestamp with millisecond precision. It offers functions that will convert to and from the system's local time zone, but it is always UTC internally. Unlike aMomentobject, it can not be set to use another time zone; It has no concept of "mode".Using
Date.parse, ornew Date(<string>)has been problematic and implemented inconsistently in the past. The current specification defines parsing a variation of ISO 8601 strings, where date-only forms (like"2020-09-14") are parsed as UTC, instead of local time as they would be by ISO 8601. Even then, not all modern implementations have implemented this specification correctly (e.g., Safari). Other types of strings may work, but parsing them is implementation specific and can vary significantly - especially with older browsers. Depending on the implementation, and the components provided in the string, you may be surprised with the result. For these reasons, we agree with MDN's statement that parsing strings with theDateobject is strongly discouraged.
Modern JavaScript environments will also implement the by ECMA-402 specification, which provides the Intl object, and defines behavioral options of the Date object's toLocaleString, toLocaleDateString, and toLocaleTimeString functions.
When using the Intl object, be aware of the following:
- Not every environment will implement the full specification. In particular, Node.js environments require internationalization support provided by ICU. See the Node.js documentation for further details.
- The ECMAScript Intl compatibility table (by kangax) can be useful in determining which features are supported and which are not.
- Most newer environments provide IANA time zone support via the
timeZoneoption in theIntl.DateTimeFormatconstructor (and inDate.toLocaleString,Date.toLocaleDateString, andDate.toLocaleTimeString). This option can be used to take the internal UTC-based timestamp of aDateobject and get a string that has been converted to a named time zone. However, it can not be used to convert aDateobject to a different time zone.
If the Date and Intl objects meet your needs and you fully understand their limitations, then you might consider using them directly.
No comments:
Post a Comment