Rule proposal: `prefer-temporal`

[sindresorhus]

The Temporal proposal is currently stage 3. It massively improves date and time handling in JavaScript.

There's a lot of potential for linting here.

We could block use of Date completely. Would probably have to be behind an option. But as far as I know, Temporal should cover everything Date currently handles.

Fail

Date.now()

Pass

Temporal.now.instant()

We could also potentially prevent use of popular date libraries like moment, Luzon, date-fns, etc.

More specific ideas for listing here wanted.

[fregante]

We could also potentially prevent use of popular date libraries like moment, Luzon, date-fns, etc.

Honestly I'd love a you-might-not-need-*-style rules. There's plenty to fix around lodash and jQuery

Edit: There are some: https://npms.io/search?q=eslint+you+dont+need

[fisker]

It seems Temporal.Now.instant().epochMilliseconds is the correct replacement for Date.now().

[fregante]

On second thought, why? Why would Temporal.Now.instant().epochMilliseconds be better than Date.now()? It's just a number in both cases and there are no improvements (unlike the new Number.* methods).

I think such rule would make more sense for every Date method except Date.now()

[sindresorhus]

@fregante It has nanosecond accuracy instead of millisecond accuracy. It also has methods that makes it easy to compare, add/subtract, and format it. And consistency is a good argument too. And the name is just plain incorrect. Date is not actually dealing with dates. Java made a big mistake calling it "date" and a lot of languages copied it. "Instant" is the correct term.

You generally wouldn't actually use Temporal.Now.instant().epochMilliseconds as you rarely need the milliseconds, but you rather usually compare or format it in some way. So you generally use and store Temporal.Now.instant().

I guess we could make it an option, but I personally can't think of any use-cases where I would prefer Date.now(). Can you?

[fregante]

I personally can't think of any use-cases where I would prefer Date.now().

I don't want to write code that looks like Java (ironically) (because it's verbose)

So you generally use and store Temporal.Now.instant().

This is still easier to read:

const start = Date.now();
console.log(Date.now() - start);

compared to:

const start = Temporal.now.instant();
console.log(start.compare(Temporal.now.instant());

You generally wouldn't actually use Temporal.Now.instant().epochMilliseconds as you rarely need the milliseconds

Good point, but sometimes you still do, and Date.now() becomes Temporal.Now.instant().epochMilliseconds, which is mouthful and not scannable at all.

It has nanosecond accuracy instead of millisecond accuracy

I think this is the only reason why it's better IMHO.

If the intention is consistency over readability, then sure, we agree, but I still think it's less readable.

[sindresorhus]

Luckily we don't have to decide this yet. We can make the option false at first and see how we feel about it after having used Temporal for a while.

[fisker]

How about just forbidding the use of Date, but allowing Date.now() behind an option?

[sindresorhus]

How about just forbidding the use of Date, but allowing Date.now() behind an option?

👍