[FrontAid]

If you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats).

- https://github.com/tc39/proposal-temporal

- https://github.com/tc39/proposal-temporal#polyfills

- https://tc39.es/proposal-temporal/

- https://tc39.es/proposal-temporal/docs/index.html

- https://github.com/tc39/proposal-temporal/issues/1450

- https://tc39.es/proposal-temporal/docs/parse-draft.html

As far as I know, issue #1450 is the last remaining blocker for the standardization. I'd assume that this will be resolved in the next months. So Temporal will likely be officially released with ECMAScript 2023, but browser vendors and other implementors will start shipping it before the offical release.

[iainmerrick]

Instead of using something that works right now, you’re saying people should hold off for a few months, then start using a prerelease API?

[jwalton]

Welllll… “works right now” is perhaps an overly strong assertion when it comes to day.js. I was working on a library we use for parsing "schedules" (like, alarm turns on at 9:00pm on Thursday, and off again at 7:00am on Friday). I was doing things like computing the number of seconds until the next scheduled transition. I tried switching from moment to day.js, and my unit tests immediately failed. Within a couple of hours I’d opened two bugs [1][2], both related to incorrect behaviour in corner cases (like generating the incorrect date when near a daylight saving time transition).

The fact that it only took me a few hours to find these suggests there are plenty more bugs like these to find. The fact that these bugs have been open since the start of March with no movement on them suggests they aren’t too interested in correct behaviour (or perhaps they’re just your typical under-staffed open source project).

Maybe I just got super unlucky and ran into the only two bugs here… but it’s not likely.

Luxon and moment.js both handled these cases perfectly. If you’re looking to move from whatever you’re using now, and you can’t wait for the new standard, I’d pick one of those.

[1]: https://github.com/iamkun/dayjs/issues/1816

[2]: https://github.com/iamkun/dayjs/issues/1817

[badlucklottery]

They mentioned "switching" which implies an already working solution. Within that context, yeah, maybe wait a few months if you can afford to.

Also, once the spec is finalized, there may also be a compliant polyfill available. If so, you'll get the functionality early and still have good compatibility down the line.

[dspillett]

If you have something working, perhaps delay refactoring to a new library.

Or as it is coming RealSoonNow(tm) perhaps start looking into polyfills as you are going to need one anyway for a story time at least to support LTS browser versions.

[michaelcampbell]

A more charitable read might be, "If you're going to change to something, you might be able to wait and make 1 change rather than 2."

[chii]

> I would suggest to hold off

you don't need to hold off - you just wrap the library in an api of your own, specific for your usage. Then, when/if the ecmascript standard library adds a good one in, you just need to re-implement the wrapper, which would be presumably pretty easy as the api surface area is fairly small.

[joenot443]

If I were helping someone start a web project _right now_ I'd probably tell them to just use Moment.js and forget about it. Any live web product I've ever worked on has always had more than enough to work on to keep updating the date-time library at the bottom of the to-do list almost indefinitely.

[anamexis]

Date libraries and small API surface areas are not usually things I associate with each other.

[yilugurlu]

Having read the cookbook [1], and wow that's a complex API out there. I can see that there will be a `Temporal Light` to allow us to do `now().startOf('month')` like calls.

[1] https://tc39.es/proposal-temporal/docs/cookbook.html

[moogly]

Wouldn't this work?

    const firstInMonth = Temporal.Now.with({ day: 1 });

[brundolf]

Moment.js was one of our biggest dependencies, and the transition to Day.js was easy. I'm certainly glad we didn't hold off. I'm sure we'll switch to Temporal eventually, but it's misguided to suggest everyone should wait a year or more to improve their sites just to save a little effort in the interim.

[qwertox]

One has also got to hope that Temporal offers all the features a well built daytime library does offer. What good is it if Temporal is lacking that one feature you need, so that you end up including another library as well.

By then you can assume that the other library will be a lightweight wrapper around Temporal.

[spankalee]

There's a good polyfill for Temporal here: https://github.com/js-temporal/temporal-polyfill