How to Validate ISO Dates in a Pasted List and Catch Fake Calendar Days

A column of dates almost always looks fine until you try to import it. The strings line up, every entry has the right number of digits, and then a downstream job rejects three rows or, worse, silently coerces 2025-02-29 into 2025-03-01. The problem is that "looks like a date" and "is a date" are two different checks, and most quick eyeballing only does the first one.

The ISO Date List Validator does both. You paste a list, or upload a local text file, and it walks every line as a candidate ISO 8601 date, then prints a pass/fail report with a reason beside each row. Everything runs in the browser tab, so a column of release dates or a log dump full of timestamps never leaves your machine.

A real ISO date is more than the YYYY-MM-DD shape

This is the part people skip. ISO 8601's calendar-date form is YYYY-MM-DD: four digits, a hyphen, two digits, a hyphen, two digits. A string can match that shape perfectly and still describe a day that has never existed.

Consider 2026-13-40. It has ten characters, two hyphens, all digits in the right slots. It passes a shallow pattern check. But month 13 does not exist, and no month has a 40th day, so it is not a valid date. The validator flags it.

Or take 2025-02-29. February has 29 days only in a leap year, and 2025 is not one (it is not divisible by 4). So 2025-02-29 is a well-formed string pointing at a day that the 2025 calendar does not contain. It gets flagged too, while 2024-02-29 and 2028-02-29 pass because those are leap years.

So the tool checks, per the manifest, that an entry is:

The YYYY-MM-DD shape (correct separators and digit positions).
A month in the range 1 to 12.
A day that actually exists for that month, including the leap-year rule for February 29.

Anything that fails one of these is kept in the report as an invalid row with the failure reason printed next to it, so the output reads like a fix list instead of just a green light. A row in the wrong order, like 24/05/2026, is flagged because it is not the ISO shape at all.

A worked example: valid rows, flagged rows, and reasons

Here is a small list of the kind I paste in constantly: a mix of clean dates and the usual suspects.

Input:

The report keeps every row, marks each one, and explains the flagged ones:

| value | valid | reason | | --- | --- | --- | | 2026-05-24 | true | OK | | 2026-13-40 | false | month 13 and day 40 are out of range | | 2025-02-29 | false | Feb 29 only exists in a leap year; 2025 is not one | | 2024-02-29 | true | OK | | 24/05/2026 | false | not the YYYY-MM-DD shape | | 2026-05-24 | true | OK (duplicate of row 1) |

Two things jump out. 2024-02-29 passes where 2025-02-29 fails, which is exactly the leap-year distinction you want a machine to make instead of trusting your memory of which years divide by 4. And the duplicate 2026-05-24 is still there. If you only want unique rows, you can turn on the dedupe option and keep one copy; if you are auditing, you leave duplicates in so the report mirrors the source.

Cleaning a whole date column, not just spotting errors

Validation is the start. The reason this tool earns a spot in a real cleanup workflow is what it lets you do with the result. After the list is checked you can:

Keep unique rows only, or preserve every invalid row for review.
Sort the normalized output so the column comes out in calendar order.
Switch the export between CSV, JSON, Markdown, a SQL IN list, a TypeScript union, or plain lines.
Download the exact artifact, with line numbers when you need an audit trail.

That last point matters more than it sounds. One of the listed common mistakes is copying only the final list when you actually needed proof of what changed. Downloading the CSV or Markdown report with the failure reasons attached turns a cleanup pass into something a teammate can re-check.

If your job is narrower than full validation, the toolbox splits the steps out. Use the ISO date extractor to pull dates out of a messy log or copied web page, the ISO date normalizer to standardize spacing and separators, the ISO date deduplicator to collapse repeats, and the ISO date list converter when you just need a format swap. The validator is the one that answers "are these all real days?"

Where I actually reach for this

I keep a tab open for this during release prep. When I am stitching a changelog together from a few different exports, the date columns come from a CRM, a ticket system, and a hand-edited spreadsheet, and every source has its own idea of what a date looks like. Last month I pasted a 200-row list and the report flagged a 2025-02-29 that a teammate had typed while back-dating an entry. Caught in two seconds, before it became a redirect rule that pointed at a day that never happened. Pasting the same list into a spreadsheet would have happily accepted it and rolled it forward to March 1, and I would never have known the date I shipped was wrong.

A few honest limits

Two caveats worth stating plainly. First, the tool checks calendar validity, not truth: a date passing validation does not mean the event on that date happened, or that the account or resource tied to it exists. It confirms the day is real, nothing more. Second, copied web text often carries hidden whitespace, so if rows that look identical are being treated as distinct, normalize before you deduplicate.

For size, the sweet spot is a few megabytes of CSV exports, server logs, or copied changelogs. If you are staring at a multi-gigabyte log, slice it locally first and paste the slice.

That is the whole loop: paste a list, see which rows are real ISO calendar dates and which only pretend to be, then export the clean column in the format your next step wants. Start with the ISO Date List Validator and let the report do the leap-year arithmetic for you.

Made by Toolora · Updated 2026-06-13