Overview
Introduction
Not every string that looks like a date is actually a real calendar date, February 30th and April 31st don't exist, and February 29th only exists in leap years.
This tool checks a YYYY-MM-DD date against real per-month day counts and the leap-year rule, and reports exactly why a date is invalid when it is.
What Is Validate a Calendar Date?
A calendar date validator that explicitly checks day-of-month bounds, including the correct leap-year exception for February, rather than relying on a date library's rollover behavior.
When a date is valid, it also reports the corresponding day of the week.
How Validate a Calendar Date Works
The input is matched against the strict YYYY-MM-DD pattern, then the month is checked to be 01-12 and the day is checked against that month's real day count for that specific year.
February's day count is computed with an explicit leap-year formula rather than a Date rollover check, so the validity check and the leap-year explanation in any error message are always consistent with each other.
When To Use Validate a Calendar Date
Use it to check a date before it's used in a calculation, form submission, or database record, especially near month or year boundaries where mistakes are common.
It's also useful any time you need to double-check whether a given year is a leap year.
Often used alongside Sort Calendar Dates, Truncate a Calendar Date and Sort Date Intervals.
Features
Advantages
- Explicit day-count and leap-year checking catches invalid dates that a naive Date-based check would silently roll over.
- Error messages explain exactly which rule was violated, including the leap-year reasoning for February specifically.
- Reports the weekday for any valid date as a useful side benefit.
Limitations
- Only validates the Gregorian calendar's YYYY-MM-DD format, not other calendar systems.
- Checks one date at a time rather than a batch list (use Calendar Date Sorter for a list, which validates every line the same way).
Examples
Best Practices & Notes
Best Practices
- Always use a four-digit year, even for dates you might think of as "this century", to avoid ambiguity.
- When checking whether February 29th is valid for a specific year, just enter it directly, the tool reports the leap-year reasoning either way.
Developer Notes
Leap years are computed with (year % 4 === 0 && year % 100 !== 0) || year % 400 === 0 against a fixed [31,28,31,30,31,30,31,31,30,31,30,31] day-count table, with February's entry overridden to 29 when the year is a leap year, all before any Date object is constructed. The weekday is derived afterward with new Date(Date.UTC(...)) only once the date is already confirmed valid, so there's no rollover risk at that point.
Validate a Calendar Date Use Cases
- Checking a user-submitted birthdate or event date for validity before storing it
- Confirming whether a specific year is a leap year for scheduling purposes
- Debugging a date-parsing bug by checking whether the underlying date was ever valid to begin with
Common Mistakes
- Assuming any year divisible by 4 is a leap year; century years like 1900 and 2100 are exceptions unless also divisible by 400.
- Entering a date with a two-digit year or a non-YYYY-MM-DD separator, which fails the strict format check before day validation even runs.
Tips
- Use this before Calendar Date Truncator or Calendar Date Sorter if you're unsure whether every date in your data is well-formed.
- The weekday shown for a valid date is a handy quick reference for scheduling without opening a separate calendar.