Date.prototype.getTime()

A Date contains nothing but this number. Everything else — components, formatting, timezones — is computed from it on demand, which explains most of the API surprises.

Date methodES1 (1997)Live demo
Common call
a.getTime() === b.getTime()
Returns
milliseconds since 1970-01-01 UTC
Replaces
comparing Dates with ===, which never works
Watch out
NaN for an invalid Date — and NaN !== NaN
date.getTime()
→ number

Demo

Live evaluation
Try:
Inputs
isostringa date string
Output
new Date('2026-03-15T12:00:00Z').getTime()
1773576000000

One number, counting milliseconds from midnight UTC on 1 January 1970 — so the epoch itself is 0 and anything earlier is negative. That single number IS the Date; there is no timezone stored anywhere in it. The invalid case gives NaN, and because NaN is never equal to itself, the idiomatic validity check is Number.isNaN(d.getTime()) rather than a comparison.

Common patterns

Compare two dates
Dates are objects — === compares references.
if (a.getTime() === b.getTime()) { }
Validity check
The standard way to test a parsed date.
const valid = !Number.isNaN(d.getTime());
Difference in days
Subtraction coerces via valueOf, so no call is needed.
const days = (b - a) / 86400000;

Examples

1. A timestamp
new Date('2026-03-15T12:00:00Z').getTime()
Returns
1773576000000
2. The epoch
new Date('1970-01-01T00:00:00Z').getTime()
Returns
0
3. Invalid is NaN
new Date('nonsense').getTime()
Returns
NaN
4. valueOf matches
new Date('2026-03-15T12:00:00Z').valueOf()
Returns
1773576000000
5. Subtraction works
new Date('2026-03-16T12:00:00Z') - new Date('2026-03-15T12:00:00Z')
Returns
86400000
6. But equality does not
new Date(0) === new Date(0)
Returns
false

Pitfalls

1. Two Dates are never === even at the same instant
They are objects, so === compares references. Two Dates built from the same timestamp are different objects and compare unequal, which makes a naive equality check silently always false.
Always false
new Date(0) === new Date(0)
false
Compare the numbers
new Date(0).getTime() === new Date(0).getTime()
true
2. But < and > DO work, and == is a special case
Relational operators coerce via valueOf, so a < b compares instants correctly — which makes the failure of === all the more confusing. Loose == does NOT coerce between two objects, so it behaves like === here.
Loose also fails
new Date(0) == new Date(0)
false
Relational is fine
new Date(0) <= new Date(0)
true
3. NaN for an invalid Date propagates silently
An unparseable date gives NaN here, and NaN flows through arithmetic and comparisons without error. A bad date can be stored and rendered before anyone notices, so check at the point of parsing.
Spreads
new Date('nonsense').getTime() + 1000
NaN
Check first
const t = new Date(s).getTime();
if (Number.isNaN(t)) reject();
fails early
4. Day arithmetic by dividing is not always right
Dividing a difference by 86 400 000 assumes every day is 24 hours. Across a daylight-saving boundary a local day can be 23 or 25 hours, so the count comes out fractional and rounding it gives the wrong answer at the edges.
Assumes 24h days
(b - a) / 86400000
0.958 across a DST spring-forward
Compare UTC dates
Math.round((Date.UTC(b.getFullYear(), b.getMonth(), b.getDate()) - Date.UTC(a.getFullYear(), a.getMonth(), a.getDate())) / 86400000)
whole days

When to use

Use it
  • Comparing two Dates for equality or ordering
  • Checking whether a parsed Date is valid
  • Storing or transmitting a date as a number
  • Measuring a difference between two instants
Reach for something else
  • Comparing Dates with === → it compares references
  • Counting calendar days across DST → compare UTC date parts
  • Measuring elapsed code time → performance.now()
  • Human-readable output → toISOString or a locale format

Notes

Complexity
O(1) — it reads the stored value directly
Return
A number, or NaN; nothing is allocated
CPython impl
V8: Builtins-date-gettime
Memory
No allocation
Thread-safe
Single-threaded

FAQ

Because arithmetic and relational operators coerce objects to primitives via valueOf, which returns the timestamp. Strict equality does no coercion at all — it compares object identity. So a - b works, a < b works, and a === b is always false for distinct objects.

b - a;          // milliseconds
a < b;          // correct
a === b;        // false, always
a.getTime() === b.getTime();   // correct

History

ES1
getTime and valueOf present from the first version; the epoch and millisecond basis inherited from Unix.
ES5
Date.now added as a shortcut for the current value.