This rule raises an issue when code creates a new Date object just to get the current timestamp as a number.

Why is this an issue?

Creating a Date object and then immediately converting it to a number is unnecessarily verbose and inefficient. JavaScript provides Date.now() as a direct way to get the current timestamp.

When you write new Date().getTime() or similar patterns, you are:

• Creating an unnecessary object instance
• Using more memory than needed
• Writing more code than necessary
• Making the intent less clear

The Date.now() method was specifically designed for this purpose. It returns the number of milliseconds since January 1, 1970 UTC, which is exactly what these other patterns achieve but in a more direct way.

Patterns like +new Date() or Number(new Date()) rely on JavaScript’s type coercion, which can be confusing for other developers reading the code. These implicit conversions make the code harder to understand at first glance.

What is the potential impact?

This issue affects code readability and performance. While the performance impact is minimal in most cases, using Date.now() is the standard, recommended approach that clearly expresses the intent to get the current timestamp.

How to fix?

Replace new Date().getTime() with Date.now() to get the current timestamp more efficiently.

Non-compliant code example

const timestamp = new Date().getTime(); // Noncompliant

Compliant code example

const timestamp = Date.now();

Documentation

• eslint-plugin-unicorn - Rule prefer-date-now
• MDN: Date.now() - Official documentation for the Date.now() method
• MDN: Date.prototype.getTime() - Documentation for the getTime() method on Date instances