The February 29th Crash

// This will crash on February 29th
function validateDate(month, day, year) {
    const daysInMonth = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31];
    
    if (day > daysInMonth[month - 1]) {
        throw new Error("Invalid date");
    }
    
    return true;
}

// February 29, 2024 will be rejected as invalid!

// This is wrong! Missing century rules
function isLeapYear(year) {
    return year % 4 === 0;
}

// This will incorrectly say 1900 is a leap year
// 1900 % 4 === 0, but 1900 is NOT a leap year!

function isLeapYear(year) {
    // Correct leap year logic with all three rules
    if (year % 400 === 0) return true;    // Rule 3: Divisible by 400
    if (year % 100 === 0) return false;   // Rule 2: Not divisible by 100
    if (year % 4 === 0) return true;      // Rule 1: Divisible by 4
    return false;
}

function getDaysInMonth(month, year) {
    const daysInMonth = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31];
    
    if (month === 2 && isLeapYear(year)) {
        return 29;  // February in leap year
    }
    
    return daysInMonth[month - 1];
}

function validateDate(month, day, year) {
    if (month < 1 || month > 12) {
        throw new Error("Invalid month");
    }
    
    const maxDays = getDaysInMonth(month, year);
    if (day < 1 || day > maxDays) {
        throw new Error(`Invalid day for ${month}/${year}`);
    }
    
    return true;
}

-- PostgreSQL: Safe date constraints
CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    event_date DATE NOT NULL,
    
    -- Don't use hardcoded day limits!
    -- CONSTRAINT bad_check CHECK (EXTRACT(DAY FROM event_date) <= 28)
    
    -- Instead, let the database handle date validation
    CONSTRAINT valid_date CHECK (event_date IS NOT NULL)
);

-- Function to validate leap year dates
CREATE OR REPLACE FUNCTION is_valid_date(y INT, m INT, d INT) 
RETURNS BOOLEAN AS $$
BEGIN
    -- Let PostgreSQL do the validation
    PERFORM make_date(y, m, d);
    RETURN TRUE;
EXCEPTION 
    WHEN others THEN
        RETURN FALSE;
END;
$$ LANGUAGE plpgsql;

from datetime import datetime, date
import calendar

def validate_date_safe(year, month, day):
    """Use Python's built-in date validation"""
    try:
        # This will raise ValueError for invalid dates
        date(year, month, day)
        return True
    except ValueError as e:
        print(f"Invalid date: {e}")
        return False

def get_days_in_month_safe(year, month):
    """Use calendar module for accurate day counts"""
    return calendar.monthrange(year, month)[1]

# Test with leap year dates
print(validate_date_safe(2024, 2, 29))  # True - valid leap day
print(validate_date_safe(2023, 2, 29))  # False - not a leap year
print(validate_date_safe(1900, 2, 29))  # False - century year exception
print(validate_date_safe(2000, 2, 29))  # True - 400-year exception

# Safe way to check if year is leap year
def is_leap_year_safe(year):
    return calendar.isleap(year)

// C# - Azure-style certificate validation fix
public static bool ValidateCertificateDate(DateTime certDate)
{
    try 
    {
        // Use .NET's built-in date validation
        // This properly handles leap years
        var validDate = new DateTime(certDate.Year, certDate.Month, certDate.Day);
        
        // Check if certificate is still valid
        return validDate >= DateTime.UtcNow;
    }
    catch (ArgumentOutOfRangeException)
    {
        // Invalid date in certificate
        return false;
    }
}

// The bug was likely something like this:
public static bool ValidateCertificateDateBuggy(int year, int month, int day)
{
    // Hardcoded validation that fails on Feb 29
    if (month == 2 && day > 28)
    {
        return false;  // BUG: Rejects valid leap day!
    }
    
    // ... rest of validation
    return true;
}