getSeconds()
ES1+Returns the seconds component of the given date according to local time, as an integer from 0 to 59. Like the other component getters it reads wall-clock digits, not elapsed time; ECMAScript time ignores leap seconds, so 60 never appears.
Syntax
date.getSeconds()Return Value
A number (0-59) representing the seconds
Examples
const date = new Date('2024-01-15T14:30:45');
console.log(date.getSeconds());📌 When to Use
Use getSeconds() when the seconds digits themselves matter: a live clock that shows HH:MM:SS, log lines with second precision, aligning an action to the top of a minute, or blinking UI elements in time with the clock. It reads the wall-clock breakdown of one instant, which makes it the wrong tool for the job it is most often misused for: measuring elapsed time. Durations should always come from subtracting timestamps (Date.now() or getTime()) and converting milliseconds to seconds, because component values wrap at 60 and go "backward" across each minute boundary. Countdown timers illustrate the split cleanly: the remaining time is a millisecond difference, and getSeconds() plays no role at all; the seconds you display are derived from that difference with Math.floor((diff % 60000) / 1000). Note two spec-level facts worth knowing. ECMAScript time has no leap seconds, so getSeconds() never returns 60 and day lengths are uniformly 86,400 SI-ish seconds as far as Date is concerned. And a handful of historical time zone offsets included seconds, but modern IANA offsets are whole minutes, so unlike getMinutes() the seconds component is effectively identical across time zones today.
⚠️ Common Mistakes
Building timers from getSeconds() deltas: subtracting two seconds values breaks the moment the interval crosses a minute (5 - 50 = -45). Elapsed seconds are Math.floor((endMs - startMs) / 1000); component getters are for display only.
Counting ticks instead of reading the clock: a countdown that decrements a variable inside setInterval(fn, 1000) drifts, because intervals are not exact and background tabs throttle them to once per minute or worse. Recompute the remaining time from Date.now() on every tick.
Expecting sub-second precision from getSeconds() by calling it rapidly; it returns whole seconds. For finer resolution use getMilliseconds() for display or performance.now() for measurement.
Forgetting zero-padding in composed strings, showing "12:03:7" instead of "12:03:07"; every component after the first needs padStart(2, "0").
Assuming leap seconds appear in JavaScript time, for example writing parsers that accept ":60" or logic reserving 61 values. ECMAScript explicitly ignores leap seconds; the OS clock smears or steps them, and Date never surfaces second 60.
✅ Best Practices
Derive countdowns and stopwatches from timestamp differences, then decompose the difference into hours, minutes, and seconds with integer division and modulo, exactly as the example does; the display then self-corrects no matter how irregularly ticks fire.
Schedule display updates just past the second boundary: setTimeout(tick, 1000 - (Date.now() % 1000)) keeps a clock visually crisp and avoids the double-update and skipped-second artifacts of naive intervals.
Use a cached Intl.DateTimeFormat with { hour: "2-digit", minute: "2-digit", second: "2-digit" } for localized clock displays; it handles padding and separators and stays consistent with your other date formatting.
Stop timers when they cannot be seen: listen for visibilitychange and pause interval work in hidden tabs, both to save battery and because throttling makes hidden-tab ticks unreliable anyway; recompute from timestamps on return.
For chronometry that must not jump with clock adjustments (a game loop, a benchmark), use performance.now(), which is monotonic; Date-based seconds can leap when NTP corrects the system clock mid-run.
⚡ Performance Notes
getSeconds() itself is a negligible cached-field read; even a per-frame call cannot show up in a profile. Timer architecture is what determines cost and correctness. A once-per-second UI update is trivially cheap, but implement it as a self-rescheduling setTimeout aligned to the second boundary rather than a bare setInterval: alignment prevents visible stutter, and recomputing state from Date.now() each tick makes throttled or delayed ticks harmless. Avoid re-rendering more often than the displayed precision changes; updating a seconds display at 60 fps does sixty times the DOM work for zero visual difference. In Node.js, prefer monotonic sources (process.hrtime.bigint() or performance.now()) for measuring, and keep Date for wall-clock labeling; mixing the two roles is the root of most flaky timing code.
🌍 Real World Example
Countdown Timer
Countdowns for sales, exam deadlines, and OTP expiry all share this structure: compute the remaining milliseconds once per tick from the target timestamp, guard the expired case, then decompose the remainder into hours, minutes, and seconds with modulo arithmetic and padded formatting. Because every tick recomputes from Date.now(), the display stays correct even if the tab was throttled or the machine slept, the failure mode that breaks decrement-a-counter implementations. The returned structured fields let the UI animate digits independently or switch to an "expired" state atomically.
function getCountdown(targetDate) {
const now = Date.now();
const target = new Date(targetDate).getTime();
const diff = target - now;
if (diff <= 0) return { expired: true };
const hours = Math.floor(diff / (1000 * 60 * 60));
const minutes = Math.floor((diff % (1000 * 60 * 60)) / (1000 * 60));
const seconds = Math.floor((diff % (1000 * 60)) / 1000);
return {
expired: false,
hours: String(hours).padStart(2, '0'),
minutes: String(minutes).padStart(2, '0'),
seconds: String(seconds).padStart(2, '0'),
display: `${hours}:${String(minutes).padStart(2, '0')}:${String(seconds).padStart(2, '0')}`
};
}
console.log(getCountdown('2024-12-31T23:59:59'));