getFullYear()
ES1+Returns the four-digit year of the date according to local time, such as 2026. It replaces the deprecated getYear(), which returned the year minus 1900. Because the result depends on the local time zone, the same Date instant can report different years on machines near a New Year boundary.
Syntax
date.getFullYear()Return Value
A number representing the year
Examples
const date = new Date('2024-01-15');
console.log(date.getFullYear());📌 When to Use
Use getFullYear() whenever you need the calendar year as the user's clock sees it: auto-updating copyright footers, age verification and birthday math, grouping records into yearly buckets for reports, building year dropdowns in forms, filtering "this year" data, or generating archive navigation for a blog. It pairs naturally with getMonth() and getDate() when you decompose a Date into calendar parts for custom formatting or for constructing a new Date at a related point in time (same day next year, first day of the current year, and so on). The local-time semantics are usually what UI code wants, since users think in their own calendar; but the same semantics make it wrong for server-side logic that must be timezone-neutral, where getUTCFullYear() keeps every machine in agreement. Be especially deliberate in the days around January 1: a timestamp late on December 31 UTC is already next year in Seoul and still the old year in Los Angeles, so analytics that bucket by getFullYear() will split the same instant differently depending on where the code runs. When your requirement is really "the year of this calendar date, independent of any clock", consider Temporal.PlainDate, which carries no time zone at all.
⚠️ Common Mistakes
Reaching for the deprecated getYear(), which returns the offset from 1900 (so 126 for 2026). It survives for backward compatibility only; any code doing 1900 + getYear() or, worse, string-concatenating "19" is a legacy bug waiting to resurface. Always use getFullYear().
Hitting the parsing timezone trap: new Date("2025-01-01").getFullYear() returns 2024 for users west of Greenwich, because the date-only ISO string is parsed as UTC midnight while getFullYear() reads local time. Construct with numeric parts (new Date(2025, 0, 1)) when you mean a local calendar date.
Computing age as currentYear - birthYear only. Until the birthday has passed this year the result is one too high; correct code also compares month and day, as the example below does. Off-by-one ages are a real compliance problem in age-gated services.
Mixing getFullYear() with UTC-based fields. Building a string from getUTCMonth() and getFullYear(), or comparing a local year against a UTC-bucketed database column, produces records that jump years near midnight on December 31.
Assuming the year is always in the modern range. Date supports years 0 through 275760 (and negative-era dates), so data corruption or epoch-seconds-versus-milliseconds mistakes surface as years like 1970 or 56138; a sanity range check on getFullYear() is a cheap data-quality guard.
✅ Best Practices
Decide local versus UTC explicitly for every use: getFullYear() for what the user's calendar shows, getUTCFullYear() for storage keys, logs, and cross-server logic. Making the choice visible in code review prevents the year-boundary class of bugs.
For a dynamic copyright line, new Date().getFullYear() evaluated at render time is the standard, dependency-free approach; on statically generated sites, remember it freezes at build time unless rendered client-side.
When you need "start of this year" or "same date last year", build the new value from parts (new Date(y, 0, 1), or setFullYear on a clone) instead of string manipulation; the Date constructor handles leap years and rollover correctly.
Prefer Intl.DateTimeFormat for displaying years to users, especially with non-Gregorian locale calendars (Buddhist, Japanese era, Hijri): new Intl.DateTimeFormat("ja-JP-u-ca-japanese", { year: "numeric" }) renders era-aware years that getFullYear() cannot express.
For pure calendar dates without time (fiscal years, birthdays), the Temporal API models the problem better: Temporal.PlainDate.from("2026-07-03").year has no timezone ambiguity, and Temporal.Now.plainDateISO().year replaces the new Date().getFullYear() idiom.
⚡ Performance Notes
getFullYear() converts the internal UTC timestamp to local time, which involves a time-zone offset lookup, and then extracts the year field. Engines cache the expanded local-time fields on the Date object, so calling several getters (getFullYear, getMonth, getDate) on the same instance costs roughly one conversion, not three. The absolute cost is tiny, tens of nanoseconds, and never worth contorting code over, but two patterns are worth avoiding in hot loops: constructing a new Date per iteration just to read the year, and calling getters on dates parsed from strings inside a sort comparator. For bucketing large datasets by year, extracting the year once per record into a plain number (or slicing the first four characters of an ISO string, when the data is UTC-normalized) keeps the loop allocation-free.
🌍 Real World Example
Age Calculator
Age calculation is the canonical getFullYear() task and also the one most often done wrong. This example subtracts birth year from current year, then corrects the result by checking whether the birthday has already occurred this year, comparing months first and days as a tiebreaker. That correction is exactly what legal age checks, insurance quotes, and school enrollment cutoffs require. The function returns structured data rather than a formatted string, leaving display formatting to the UI layer where locale rules belong.
function calculateAge(birthDate) {
const today = new Date();
const birth = new Date(birthDate);
let age = today.getFullYear() - birth.getFullYear();
const monthDiff = today.getMonth() - birth.getMonth();
// Adjust if birthday hasn't occurred yet this year
if (monthDiff < 0 || (monthDiff === 0 && today.getDate() < birth.getDate())) {
age--;
}
return {
age,
birthYear: birth.getFullYear(),
nextBirthday: `${birth.getMonth() + 1}/${birth.getDate()}`
};
}
console.log(calculateAge('1990-06-15'));
// { age: 33, birthYear: 1990, nextBirthday: '6/15' }