Date Format Checker
01/02/2026 is 1 February in most of the world and 2 January in the United States.
Same characters, a month apart, and no importer will warn you. Paste a date to see every reading
it has — with the weekday, which is usually how you can tell which one is yours.
🔒 Your data never leaves your browser.
Why a date column is more dangerous than it looks
A date has no self-describing format. 03/04/2026 is a perfectly valid date under
two different conventions, so no parser can reject it and none will tell you which one it
chose. The failure is silent, it only affects the rows where both numbers happen to be twelve
or lower, and it survives every round of eyeballing — which is exactly why it reaches
production.
The one format that cannot be read two ways is ISO 8601:
2026-02-01. Year first, descending order of significance. It also sorts correctly
as plain text, which is a free bonus every other format denies you.
The number that is secretly a date
Spreadsheets store dates as a count of days. Export a column whose cells were never formatted
as dates and you get the raw count — 45658 instead of a date. The count is exact
and reversible, so this tool decodes it:
1→ 1900-01-0160→ 29 February 1900 — a day that never existed61→ 1900-03-0125569→ 1970-01-0145658→ 2025-01-01
That gap at 60 is not a mistake in this tool. Spreadsheets deliberately reproduce
a 1983 bug that treats 1900 as a leap year, for compatibility with an even older product.
Serial 60 therefore points at 29 February 1900, a date that does not exist, and every serial
below 61 is offset by one day from the naive formula. Date arithmetic that crosses that
boundary is wrong by a day.
There is a second trap: workbooks saved by older Mac versions count from 1 January 1904 instead, putting the same serial 1462 days — just over four years — away. Nothing in an exported CSV records which epoch produced the number, so this tool shows the default reading and names the alternative rather than pretending there is only one.
A time without a zone is not a moment
2026-02-01T00:00:00 is midnight somewhere, but the string does not say where.
Google Merchant Center does not simply fall back to UTC: for text and XML feeds it applies the
target country’s default zone, while the API uses UTC. The same string can therefore mean two
different instants depending on how you submit it, which moves a sale window by up to a day at
each end.
Merchant Center expects a range as start/end — for example
2026-02-01T00:00:00-0800/2026-02-28T23:59:59-0800. A range whose end precedes its
start is accepted and simply never runs, so this tool checks the direction too.
Every check this tool runs (14 rules)
DATE-A01Ambiguous day/month order
Both numbers are 12 or lower, so the value is a valid date under either convention. "01/02/2026" is 1 February almost everywhere and 2 January in the United States — a month apart, with no error from any parser.
Fix: Re-export the column as ISO 8601 (2026-02-01). It is the only format that cannot be read two ways.
Source: Derived from the calendar itself (the Gregorian leap rule and the number of days in each month) and from the arithmetic of spreadsheet date serial numbers, which our tests verify against three independent fixed points.
DATE-A02Two-digit year
A two-digit year has to be guessed into a century, and tools disagree about where the window falls — some treat 30-99 as 19xx, others use a sliding window relative to today. The same file imported next year can produce different dates.
Fix: Write the year in full: 2026, not 26.
Source: Derived from the calendar itself (the Gregorian leap rule and the number of days in each month) and from the arithmetic of spreadsheet date serial numbers, which our tests verify against three independent fixed points.
DATE-A03Compact date with no separators
Eight digits with no separators can be YYYYMMDD, DDMMYYYY or MMDDYYYY. YYYYMMDD is the common intent, but the other readings are valid dates too and nothing in the value says which one you meant.
Fix: Add separators and use ISO order: 2026-02-01.
Source: Derived from the calendar itself (the Gregorian leap rule and the number of days in each month) and from the arithmetic of spreadsheet date serial numbers, which our tests verify against three independent fixed points.
DATE-A04Unambiguous only by luck
This particular value can only be read one way because one component is greater than 12 — but the format itself is ambiguous, so other rows in the same column may be silently misread.
Fix: Check the whole column, not just this row. A format that is safe for the 13th is not safe for the 2nd.
Source: Derived from the calendar itself (the Gregorian leap rule and the number of days in each month) and from the arithmetic of spreadsheet date serial numbers, which our tests verify against three independent fixed points.
DATE-E01Excel date serial number
The value is a bare number where a date was expected. Spreadsheets store dates as a count of days, and exporting a column whose cells were never formatted as dates writes the raw count instead — 45658 rather than 2025-01-01.
Fix: In the spreadsheet, format the column as a date (or use TEXT(cell,"yyyy-mm-dd")) before exporting.
Source: Derived from the calendar itself (the Gregorian leap rule and the number of days in each month) and from the arithmetic of spreadsheet date serial numbers, which our tests verify against three independent fixed points.
DATE-E02Serial 60 is a date that never existed
Spreadsheets deliberately reproduce a 1983 bug that treats 1900 as a leap year, so serial 60 maps to 29 February 1900 — a day that did not happen. Every serial below 61 is therefore offset by one day from the naive formula, which is why date arithmetic across that boundary goes wrong.
Fix: Treat any serial under 61 as suspect and re-export those rows as text dates.
Source: Derived from the calendar itself (the Gregorian leap rule and the number of days in each month) and from the arithmetic of spreadsheet date serial numbers, which our tests verify against three independent fixed points.
DATE-E03Two spreadsheet epochs exist
The default epoch counts from 30 December 1899, but workbooks saved by older Mac versions count from 1 January 1904. The same serial is 1462 days — just over four years — apart between the two, and nothing in an exported CSV records which epoch was used.
Fix: Confirm the epoch in the source workbook, or ask for the dates as text.
Source: Derived from the calendar itself (the Gregorian leap rule and the number of days in each month) and from the arithmetic of spreadsheet date serial numbers, which our tests verify against three independent fixed points.
DATE-U01Unix timestamp
Ten digits is a count of seconds since 1970 and thirteen digits is a count of milliseconds. Both are timestamps that leaked out of a database or an API into a field that expects a calendar date.
Fix: Convert to ISO 8601 before writing the feed.
Source: Derived from the calendar itself (the Gregorian leap rule and the number of days in each month) and from the arithmetic of spreadsheet date serial numbers, which our tests verify against three independent fixed points.
DATE-V01Impossible date
The components form a date that does not exist — a 31st in a 30-day month, or 29 February in a year that is not a leap year. The Gregorian leap rule is every four years, except centuries, except centuries divisible by 400.
Fix: Check the source value; this is usually an off-by-one or a bad string concatenation.
Source: Derived from the calendar itself (the Gregorian leap rule and the number of days in each month) and from the arithmetic of spreadsheet date serial numbers, which our tests verify against three independent fixed points.
DATE-V02Not a date
No date could be read from this value under any convention this tool knows.
Source: Derived from the calendar itself (the Gregorian leap rule and the number of days in each month) and from the arithmetic of spreadsheet date serial numbers, which our tests verify against three independent fixed points.
DATE-T01No time zone
A timestamp without a zone is not a moment — it is a moment in whichever zone the reader assumes. Google Merchant Center does not simply assume UTC: for text and XML feeds it applies the target country’s default zone, while the API uses UTC. The same string can therefore mean two different instants depending on how you submit it, which shifts a sale window by up to a day at each end.
Fix: Append the offset explicitly, as in 2026-02-01T00:00:00-0800.
DATE-T02ISO 8601 — unambiguous
Year-month-day in descending order of significance. It has exactly one reading, it sorts correctly as plain text, and it is what feed specifications ask for.
DATE-G01Date range
A range is a start and an end separated by a slash: start/end. Merchant Center uses this form for the sale price effective date, and both halves follow the same date-and-time rules.
DATE-G02Range ends before it starts
The end of the range is earlier than its start, so the window never opens. A sale submitted this way simply does not run, and nothing rejects the row.
Fix: Swap the two halves, or check whether one of them was written with the wrong day/month order.
Month names are recognised in English only. The time-zone and range rules follow Google Merchant Center — Format date and time; everything else is derived from the calendar and from spreadsheet serial arithmetic, which our tests verify against three independent fixed points.