getMinutes()
ES1+Returns the minutes component of the given date according to local time, as an integer from 0 to 59. It reads only the minute field of the wall-clock breakdown; it is not a duration in minutes, nor does it include hours.
Syntax
date.getMinutes()Return Value
A number (0-59) representing the minutes
Examples
const date = new Date('2024-01-15T14:30:45');
console.log(date.getMinutes());📌 When to Use
Use getMinutes() when you need the minute hand of the wall clock: composing custom time displays, checking whether an appointment starts on the half hour, rounding times to the nearest 5- or 15-minute slot in scheduling UIs, driving a clock component, or aligning polling to minute boundaries. It is a component extractor, so it always appears alongside getHours() (and sometimes getSeconds()) rather than alone; a bare minute number is rarely meaningful without its hour. Two boundary cases deserve respect. First, some real time zones have offsets that are not whole hours (India at UTC+05:30, Nepal at UTC+05:45), so the minutes of the same instant differ across zones; never assume the minute component is timezone-invariant, and use getUTCMinutes() when the value feeds shared logic. Second, do not use clock components to measure elapsed time: end.getMinutes() - start.getMinutes() goes negative whenever an interval crosses an hour boundary. Durations belong to timestamp subtraction, with the difference converted to minutes by dividing by 60,000. For displaying times to users, prefer toLocaleTimeString or Intl.DateTimeFormat over manual composition, since locales differ in separators, padding, and 12/24-hour conventions.
⚠️ Common Mistakes
Rendering single-digit minutes without padding, producing "9:5 PM" instead of "9:05 PM". Minutes must be zero-padded for display: String(m).padStart(2, "0"). Locale formatters do this automatically, which is one more reason to prefer them for UI.
Measuring durations with clock fields: a task from 10:50 to 11:05 gives getMinutes() values 50 and 5, and naive subtraction says -45. Elapsed time is (end.getTime() - start.getTime()) / 60000; clock components are display data, not arithmetic operands.
Assuming all time zones sit on whole hours, so that minutes match UTC minutes everywhere. In Kolkata (UTC+05:30) an instant with UTC minutes 00 shows local minutes 30; hardcoded "minutes are the same everywhere" assumptions corrupt cross-zone displays.
Scheduling with setTimeout(fn, 60000) loops and expecting alignment to real minutes: timer drift accumulates, and throttled background tabs delay timers by minutes. Re-read the actual time each tick and compute the delay to the next minute boundary instead.
Confusing getMinutes() with getTime()-based minute counts or with getTimezoneOffset() (which is expressed in minutes); each answers a different question, and mixing them produces plausible numbers that are semantically wrong.
✅ Best Practices
Format times for users with toLocaleTimeString(locale, { hour: "numeric", minute: "2-digit" }) or a cached Intl.DateTimeFormat; you get padding, separators, and 12/24-hour behavior correct in every locale with zero conditional code.
When composing strings manually (for logs or fixed-format IDs), always pad: `${h}:${String(m).padStart(2, "0")}`, and keep such formats machine-oriented; anything user-facing should go through Intl.
Round to slot boundaries with arithmetic on a clone: minutes = Math.round(d.getMinutes() / 15) * 15; setMinutes(minutes, 0, 0) snaps to quarter-hours, and setMinutes gracefully normalizes 60 into the next hour.
To fire on the next minute boundary, compute the remaining milliseconds (60000 - (Date.now() % 60000)) for a one-shot setTimeout, then reschedule each tick; this self-corrects drift that fixed-interval timers accumulate.
Convert millisecond durations to human units in one utility (minutes = Math.floor(ms / 60000), seconds = Math.floor(ms % 60000 / 1000)) so countdowns and elapsed displays share a single, tested formatter.
⚡ Performance Notes
getMinutes() is a cached-field read with effectively zero cost; you can call it every animation frame without measurable impact. The performance considerations live in the surrounding time-display machinery. A ticking clock component should update once per second (or per minute if seconds are hidden), scheduled with a boundary-aligned setTimeout rather than a 16 ms interval that re-renders sixty times more often than the display changes. When formatting many times, cache one Intl.DateTimeFormat and call format() repeatedly; creating formatters per call is the dominant cost in list rendering, easily thousands of times the cost of the getter itself. And background-tab throttling means interval-driven clocks stall; re-deriving the display from new Date() on each tick, as the example does, guarantees correctness whenever the tab wakes.
🌍 Real World Example
Meeting Time Formatter
Meeting and calendar interfaces constantly render times like "9:05 AM", and this example shows the two details manual formatting must get right: converting the 24-hour value with hours % 12 || 12 so midnight and noon both read 12, and zero-padding minutes with padStart so 9:5 never appears. Encapsulating both in one formatter function keeps every screen consistent and gives you a single seam to swap in Intl.DateTimeFormat when localization arrives. The same composition appears in chat message timestamps, booking confirmations, and printable schedules.
function formatMeetingTime(date) {
const d = new Date(date);
const hours = d.getHours();
const minutes = d.getMinutes();
const ampm = hours >= 12 ? 'PM' : 'AM';
const hour12 = hours % 12 || 12;
return `${hour12}:${String(minutes).padStart(2, '0')} ${ampm}`;
}
console.log(formatMeetingTime('2024-03-15T09:05:00')); // "9:05 AM"
console.log(formatMeetingTime('2024-03-15T14:30:00')); // "2:30 PM"