Leap Year

A leap year is a calendar year containing an extra day (February 29) to keep the calendar synchronized with Earth's orbit around the Sun. Earth's orbital period is approximately 365.2422 days (365 days, 5 hours, 48 minutes, 46 seconds), not exactly 365 days.

Without leap years: The calendar would drift by about 6 hours per year, causing seasons to shift over time. After 100 years, the calendar would be off by approximately 24 days, meaning summer would eventually occur in winter months.

How it works: By adding one extra day every 4 years, we compensate for the accumulated fractional days (0.25 days × 4 years = 1 day). However, this slightly overcorrects (adding 0.25 days per year when we only need 0.2422), so additional rules refine the system.

Historical context: The Julian calendar (introduced 45 BCE) added a leap day every 4 years but accumulated an error of 11 minutes per year. By 1582, this caused a 10-day drift. Pope Gregory XIII introduced the Gregorian calendar with refined leap year rules to fix this.

The Gregorian calendar uses a three-rule system to determine leap years with exceptional accuracy:

Rule 1: Divisible by 4
• If a year is divisible by 4, it is a leap year
• Example: 2024 ÷ 4 = 506 (no remainder) → Leap year
• Example: 2023 ÷ 4 = 505.75 (has remainder) → Not a leap year

Rule 2: Exception for Century Years (Divisible by 100)
• If a year is divisible by 100, it is NOT a leap year
• This corrects the overcorrection from Rule 1
• Example: 1900 ÷ 100 = 19 → Not a leap year (even though divisible by 4)
• Example: 2100 ÷ 100 = 21 → Not a leap year

Rule 3: Exception to the Exception (Divisible by 400)
• If a year is divisible by 400, it IS a leap year
• This fine-tunes the calendar even further
• Example: 2000 ÷ 400 = 5 → Leap year (overrides Rule 2)
• Example: 1600 ÷ 400 = 4 → Leap year

Complete Algorithm:
if (year % 400 === 0) return true; // Leap year
if (year % 100 === 0) return false; // Not a leap year
if (year % 4 === 0) return true; // Leap year
return false; // Not a leap year

Recent and Upcoming Examples:
• 2000: Leap year (divisible by 400)
• 1900: Not a leap year (divisible by 100, not by 400)
• 2020, 2024, 2028: Leap years (divisible by 4)
• 2100: Not a leap year (divisible by 100, not by 400)
• 2400: Leap year (divisible by 400)

The Gregorian calendar is remarkably accurate but will still drift very slowly over millennia. Understanding this helps appreciate the precision of the leap year system.

Current Accuracy:
• The Gregorian calendar year averages 365.2425 days
• The true solar year (tropical year) is 365.2422 days
• Error: Only 0.0003 days (26 seconds) per year
• This means the calendar drifts by 1 day every 3,333 years

Comparison to Previous Systems:
• Julian calendar: 365.25 days average → Error of 11 minutes/year → 1 day drift every 128 years
• Gregorian calendar: 365.2425 days average → Error of 26 seconds/year → 1 day drift every 3,333 years
• Improvement: 26× more accurate than Julian calendar

Long-Term Drift:
By year 4909 (about 2,884 years from now), the Gregorian calendar will be 1 day ahead of the solar year. However, Earth's rotation is gradually slowing (days are getting longer by ~1.7 milliseconds per century), making long-term predictions complex.

Potential Future Adjustments:
Some proposals suggest skipping leap years in years divisible by 4000 (e.g., year 4000 would not be a leap year), which would improve accuracy to 1 day drift every 20,000 years. However, no changes are planned or necessary for many centuries.

Practical Impact:
For all practical purposes in modern software, business, and daily life, the Gregorian calendar is accurate enough that the drift is negligible. The 26-second annual error is far smaller than other calendar considerations like leap seconds added to UTC.

Implementing leap year logic requires following the Gregorian calendar rules precisely. Here are correct implementations across popular languages:

JavaScript / TypeScript:
function isLeapYear(year) {
return (year % 4 === 0 && year % 100 !== 0) || (year % 400 === 0);
}

// Alternative using Date object
function isLeapYearAlt(year) {
return new Date(year, 1, 29).getDate() === 29;
}

// Usage
console.log(isLeapYear(2024)); // true
console.log(isLeapYear(2100)); // false
console.log(isLeapYear(2000)); // true

Python:
def is_leap_year(year):
return (year % 4 == 0 and year % 100 != 0) or (year % 400 == 0)

# Using calendar module
import calendar
calendar.isleap(2024) # True

# Get number of days in February
calendar.monthrange(2024, 2)[1] # 29

Java:
public static boolean isLeapYear(int year) {
return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0);
}

// Using Java 8+ java.time
import java.time.Year;
boolean leap = Year.of(2024).isLeap(); // true

C / C++:
bool isLeapYear(int year) {
return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0);
}

// Or more explicitly
bool isLeapYear(int year) {
if (year % 400 == 0) return true;
if (year % 100 == 0) return false;
if (year % 4 == 0) return true;
return false;
}

PHP:
function isLeapYear($year) {
return ($year % 4 == 0 && $year % 100 != 0) || ($year % 400 == 0);
}

// Using DateTime
$date = new DateTime("$year-02-29");
$isLeap = $date->format('Y') == $year; // true if Feb 29 exists

SQL (Multiple Databases):
-- PostgreSQL / MySQL / SQL Server
SELECT CASE
WHEN year % 400 = 0 THEN 1
WHEN year % 100 = 0 THEN 0
WHEN year % 4 = 0 THEN 1
ELSE 0
END AS is_leap_year;

-- Or as a function
CREATE FUNCTION is_leap_year(year INT) RETURNS BOOLEAN AS $$
BEGIN
RETURN (year % 4 = 0 AND year % 100 != 0) OR (year % 400 = 0);
END;
$$ LANGUAGE plpgsql;

Excel Formula:
=OR(MOD(A1,400)=0, AND(MOD(A1,4)=0, MOD(A1,100)<>0))

Common Mistakes to Avoid:
• Wrong: year % 4 == 0 (ignores century rules)
• Wrong: Checking only divisibility by 400 and 4
• Correct: Must check all three rules in proper order

Leap years create specific challenges in software that can cause bugs, data errors, and system failures if not properly handled. Understanding these implications is critical for robust applications.

Date Validation and Input:

Problem: Invalid dates like February 29 in non-leap years
• User enters "2023-02-29" in a form
• System must validate and reject invalid dates
• Solution: Use date libraries that validate automatically:
// JavaScript
const date = new Date('2023-02-29');
console.log(date.toISOString()); // "2023-03-01T00:00:00.000Z"
// Silently converts to March 1! Must validate explicitly.

Birthday and Anniversary Logic:

Problem: People born on February 29
• When should "leap day babies" celebrate in non-leap years?
• Legal age calculations may vary by jurisdiction
• Common Solutions:
- Celebrate on February 28 in non-leap years
- Celebrate on March 1 in non-leap years
- Let user choose preference
- For legal purposes, many jurisdictions consider Feb 28 as the birthday

Age Calculation Example:
// Person born Feb 29, 2000, checking age on Feb 28, 2025
const birthDate = new Date('2000-02-29');
const checkDate = new Date('2025-02-28');
let age = checkDate.getFullYear() - birthDate.getFullYear();
// Has birthday occurred this year?
if (checkDate.getMonth() < birthDate.getMonth() ||
(checkDate.getMonth() === birthDate.getMonth() &&
checkDate.getDate() < birthDate.getDate())) {
age--; // Birthday hasn't occurred yet
}
// Result: age = 24 (birthday is tomorrow)

Financial and Accounting Systems:

Problem: Interest calculations and billing cycles
• Leap years have 366 days instead of 365
• Affects daily interest calculations
• Impact on calculations:
- 30/360 convention ignores leap days
- Actual/365 uses 365 even in leap years (simplified)
- Actual/Actual accounts for 366 days in leap years (precise)

Example: Daily interest for $10,000 at 5% annual:
• Non-leap year: $10,000 × 5% ÷ 365 = $1.37 per day
• Leap year (Actual/366): $10,000 × 5% ÷ 366 = $1.37 per day
• Leap year (Actual/365): $10,000 × 5% ÷ 365 = $1.37 per day (ignores leap)

Database Storage:

Problem: Date storage and indexing
• Always store dates as proper DATE or TIMESTAMP types
• Never store as strings without validation
• Bad: VARCHAR '02/29/2023' (invalid but stored)
• Good: DATE column with constraint validation

Testing and Quality Assurance:

Critical Test Cases:
✓ Test with February 29 in leap years (2024, 2028)
✓ Test with February 29 in non-leap years (should fail)
✓ Test century years: 1900 (not leap), 2000 (leap)
✓ Test date arithmetic across Feb 28/29 boundary
✓ Test age calculations for Feb 29 birthdays
✓ Test recurring events (monthly, yearly) in leap years
✓ Test year-end to year-start transitions

Subscription and Renewal Systems:

Problem: Annual subscriptions starting on Feb 29
• Subscription starts: February 29, 2024
• Renewal due: February 29, 2025 (doesn't exist)
• Solutions:
- Renew on February 28 in non-leap years
- Renew on March 1 in non-leap years
- Store renewal as "1 year from start" not absolute date

Logging and Audit Trails:

Problem: Missing audit logs on February 29
• Daily backup script runs "every day"
• Script dates: Feb 28 → March 1 (skips Feb 29 if year check wrong)
• Solution: Use proper date increment functions, not day counting