Leap year — Gregorian 4 / 100 / 400 rule explained

Where leap-year knowledge matters in practice

Leap-year determination is not just calendar trivia: it directly affects software bugs, financial calculations, and legal deadline arithmetic. Systems that incorrectly treated 1900 as a leap year caused real data errors, and part of the Y2K concern was that date-handling code had not implemented the Gregorian rule — divisible by 400 overrides the 100-year exception — correctly.

For people born on February 29, the question of when the next Feb 29 arrives is relevant to birthday planning, age-related legal milestones, and sometimes insurance or pension eligibility. This is a straightforward calculation that should not require sending a birth year to an external service.

Why not to depend on an external API for leap-year checks

Leap-year determination is three modular arithmetic tests: divisible by 4, AND not by 100, OR by 400. It is one of the most self-contained calculations in computing. Tools that nonetheless fetch the answer from an external API create unnecessary dependencies: the API can go down, throttle requests, or log which years were queried. Querying ‘is year X a leap year’ when X is a birth year is effectively disclosing a year of birth to the API provider.

External calendar services also vary in which calendar system they implement. If you need Gregorian leap-year rules and the service defaults to a Julian or other system for certain year ranges, the result can be silently wrong. Running the check in your own browser against a known implementation eliminates that ambiguity.

Gregorian rules implemented with the JavaScript % operator

This tool implements the three Gregorian rules using the % (modulo) operator: a year is a leap year if (year % 4 === 0 && year % 100 !== 0) || year % 400 === 0. The result is cross-checked with new Date(year, 1, 29).getDate() === 29, which lets the JavaScript engine confirm the answer against its own Gregorian implementation.

The list of the nearest 10 leap years is a simple scan of ±40 years from the target, applying the same test. The ‘next Feb 29’ countdown uses the same logic. Open DevTools Network and change the year: no requests fire.

Using the tool for software development and life planning

For software development, the results for 1900, 2000, and 2100 are the key test cases to verify against your implementation: 1900 must be a common year, 2000 a leap year, 2100 a common year. Use this tool to confirm those values when writing date-handling tests.

For Feb 29 birthdays, note that the gap between leap years is usually 4 years but occasionally 8 years (when a century year is skipped — the next such gap will be 2096 to 2104). The ‘next Feb 29’ counter handles those extended gaps correctly.

Gregorian reform history and calendar systems beyond it

The current Gregorian calendar was introduced by Pope Gregory XIII in 1582 to fix an error in the Julian calendar (45 BCE), which used a flat “every 4 years” leap rule. The Julian year averages 365.25 days, but the actual solar year is 365.2422 days, accumulating about one day of drift per 128 years. The Gregorian 4 / 100 / 400 rule (97 leap years per 400-year cycle) holds the error down to one day per 3,300 years. The transition skipped ten days — the day after 1582-10-04 was 1582-10-15 — and the British Empire (including the American colonies) delayed adoption until 1752, which is why the Unix cal 9 1752 command famously shows September 2 followed directly by September 14.

JavaScript’s Date object uses the proleptic Gregorian calendar, meaning the Gregorian rule is applied retroactively to dates before 1582 — new Date(1500, 1, 29) is not how the Julian calendar would have treated that year. Intl.DateTimeFormat accepts a calendar option to switch to julian, hebrew, islamic, chinese, or japanese calendars. The Japanese imperial calendar has aligned with Gregorian since 1873 and shares its leap rules, but era boundaries (Reiwa starting on 5/1/2019) require care when displaying or computing dates that straddle them.

Historical leap-year bugs and the standard implementation pattern

Leap-year bugs have appeared in commercial software repeatedly. Microsoft Excel notoriously treats 1900 as a leap year for Lotus 1-2-3 compatibility, and the bug remains in modern Excel — DATE(1900, 2, 29) still returns a valid date even though 1900 is divisible by 100 without being divisible by 400. In 2012, Microsoft Azure had a global outage caused by a leap-year handling bug; Windows Phone scheduling apps stalled for a full day around the same date. On 2024-02-29, Tesla and OpenSea reported related issues.

The standard implementation is the single expression (year % 4 === 0 && year % 100 !== 0) || year % 400 === 0. Parenthesisation can be omitted because && binds tighter than ||, but explicitly grouping (as in the form above) makes the intent clearer and avoids precedence mistakes when the same logic is translated to SQL AND/OR (where the precedence is the same but errors are common) or to languages with different defaults. Standard test cases are 1900 (not leap), 2000 (leap), 2024 (leap), 2100 (not leap), and 2400 (leap) — these five values cover every branch of the rule and are the industry baseline for date-handling test suites. To compute the legal full age for a February 29 birthday (which most jurisdictions advance on February 28 in common years), age-calc handles that; for a day-by-day count to the next Feb 29 milestone, date-diff keeps the input year out of any server log.