oxc-project/oxc · warning · OxcDiagnostic

Unnecessary `.getTime()` call

Error message

Unnecessary `.getTime()` call

What it means

Diagnostic from oxlint's `unicorn/consistent-date-clone` rule. The `Date` constructor clones a `Date` directly when passed as the argument, so converting to epoch millis with `.getTime()` and back is redundant; the rule flags that pattern. Detection is narrow: a `new Date(...)` with exactly one argument, no type arguments, whose argument is a zero-argument, non-optional-chained `.getTime()` call — an autofix deletes the `.getTime()` suffix.

Source

Thrown at crates/oxc_linter/src/rules/unicorn/consistent_date_clone.rs:9

use crate::{AstNode, context::LintContext, rule::Rule};
use oxc_ast::AstKind;
use oxc_ast::ast::{Argument, Expression};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};

fn consistent_date_clone_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Unnecessary `.getTime()` call")
        .with_help("Prefer passing `Date` directly to the constructor when cloning")
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct ConsistentDateClone;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// The Date constructor can clone a `Date` object directly when passed as an argument,
    /// making timestamp conversion unnecessary. This rule enforces the use of the
    /// direct `Date` cloning instead of using `.getTime()` for conversion.
    ///
    /// ### Why is this bad?
    ///
    /// Using `.getTime()` to convert a `Date` object to a timestamp and then back to a
    /// `Date` is redundant and unnecessary. Simply passing the `Date` object to the

View on GitHub (pinned to e1e7af627c)

Solutions

1. Pass the Date directly: `const copy = new Date(original);`.
2. Run `oxlint --fix` to strip the redundant `.getTime()` calls automatically.
3. Reserve `.getTime()` for arithmetic on epoch milliseconds, not for cloning.

Example fix

// before
const copy = new Date(original.getTime());
// after
const copy = new Date(original);

When it happens

Trigger: `const copy = new Date(original.getTime());` or `new Date(this.startsAt.getTime())` — any `new Date(x.getTime())` where the call is a plain member call with no arguments and no optional chaining.

Common situations: Date cloning in schedulers/calendars and immutable state updates; code written to avoid the deprecated `new Date(dateString)` pitfall by over-generalizing to timestamps; enabling the unicorn preset in an older codebase.

Related errors

• The catch parameter {caught_ident:?} should be named {expect
• Inconsistent assert usage.
• Prefer consistent types when spreading a ternary in an array
• Prefer `{} {}` over `{} {}` to check {}.
• Function `{name}` does not capture any variables from its pa

AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/9d0881af76baaba1. Report an issue: GitHub.