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:

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();

Exceptions

No issue will be raised when new Date().getTime() or +(new Date()) is used inside a polyfill pattern that checks for Date.now availability. These patterns are common in legacy code to provide compatibility with older environments that don’t support Date.now().

The following polyfill patterns are recognized:

// Logical OR polyfill
const now = Date.now || function() { return new Date().getTime(); };

// Ternary polyfill
const timestamp = Date.now ? Date.now() : +(new Date());

// If statement polyfill
if (!Date.now) {
  Date.now = function() {
    return new Date().getTime();
  };
}

Documentation