Hacker News Reader

Comment by FrontAid | Hacker News Reader

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.

View on HN

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?

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.

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.

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

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."

> 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.

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

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.

I was tangentially involved in the back-end data part of a web project in the last few weeks.

Right from the beginning, I told anyone who would listen that the underlying data was in UTC. So far, so good.

They get to T-24h for the client's Big Demo Day...

...and someone in London, UK notices the front end UI times are all an hour out (that would be because the UK is still on summer time, UTC+1). I happened to be in Germany and after finally being given a login for the UI found that, wonder of wonders, the timings were two hours out!

<groan>

So we had to bodge the API to fiddle the times forward to UTC+1 for the purposes of the damned demo.

Someone is presumably going to find this in the repo waaaay in the future and ask themselves "wtf were they thinking?". I wish I knew the answer.

Moment’s website suggests using other more modern alternatives so probably not a good idea to use it on a new project.

I wouldn't recommend anyone use moment.js if they're starting a new project. It's an unnecessarily large library, and the fact that moment objects are mutable almost always causes more issues than it solves. The only reason to use it is if you're working on software that is already using it. Otherwise use a more modern, immutable datetime library like day.js, date-fns, or luxon.

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

Wouldn't this work?

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

Correction:

  Temporal.Now.plainDateISO().with({ day: 1 })

Today (2022-10-10 on my computer), that’ll get you a PlainDate representing 2022-10-01.

The “ISO” in there identifies the calendar. Want to know what the first of the current month in the Hebrew calendar is?

  Temporal.Now.plainDate("hebrew").with({ day: 1 })

And that gives you 2022-09-26[u-ca=hebrew].

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.

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.

Temporal looks fantastic from what I've seen, it's a very filled-out spec, and yeah, at the very least it should make these kinds of libraries smaller

I just think it was needlessly assertive to say nobody should migrate their datetime library until it's ready

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

Reply on news.ycombinator.com