This rule raises an issue when new Date() is called with date.getTime() as an argument instead of passing the Date object directly.

Why is this an issue?

The JavaScript Date constructor can accept another Date object directly as an argument to create a clone. When you pass date.getTime() to new Date(), you are unnecessarily converting the date to a timestamp first, then back to a Date object.

This approach has several drawbacks:

• Reduced readability: The code is more verbose and less clear about the intent to clone a date
• Unnecessary computation: Converting to timestamp and back involves extra processing steps
• Less idiomatic: Modern JavaScript (ES2015+) supports direct date cloning, making this the preferred approach

The direct approach new Date(date) is cleaner, more efficient, and clearly expresses the intent to create a copy of an existing date.

What is the potential impact?

This issue primarily affects code readability and maintainability. While the performance impact is minimal, using the direct cloning approach makes the code more idiomatic and easier to understand for other developers.

How to fix?

Pass the Date object directly to the Date constructor instead of calling getTime() first.

Non-compliant code example

const originalDate = new Date();
const clonedDate = new Date(originalDate.getTime()); // Noncompliant

Compliant code example

const originalDate = new Date();
const clonedDate = new Date(originalDate);

Documentation

• eslint-plugin-unicorn - Rule consistent-date-clone
• MDN - Date constructor - Official documentation for the Date constructor, including examples of cloning dates
• MDN - Date.prototype.getTime() - Documentation for the getTime() method and when to use it