Darwin Core · dwc:eventDate · ISO 8601
What you are seeing RECORDED_DATE_INVALID RECORDED_DATE_UNLIKELY
Darwin Core's eventDate is ISO 8601. A single day is 2024-03-17. A range is two of those separated by a solidus — 2024-03-17/2024-03-21. Reduced precision is legal and useful: 2024-03 means you know the month and not the day, and 2024 means you know the year.
01/02/2024 is the case worth understanding, and GBIF's own behaviour here is better than people assume. Their documentation says non-ISO formats "may be interpreted, where we can do so without ambiguity, but these formats are not recommended" — so GBIF does not quietly pick a reading it cannot justify. A date it cannot resolve is flagged RECORDED_DATE_INVALID rather than guessed at. Whether 01/02/2024 is 1 February or 2 January depends on the locale of whatever wrote the file, and that locale is recorded nowhere in it.
The silent damage happens earlier, in your own toolchain. GBIF declines to guess; a spreadsheet does not. Excel will reinterpret a date column on open according to the machine's regional settings, a Python or R script will apply whatever format string it was given, and each of those will hand you a confident answer. By the time the file reaches GBIF the ambiguity has usually been resolved already — correctly or not — and nothing records which. Where the day is 13 or higher the original order is recoverable; where it is 12 or lower it is not, and a file mixing both conventions cannot be repaired from its own contents at all. We refuse a date column we cannot settle rather than guessing, for the same reason GBIF does.
The other common cause of RECORDED_DATE_INVALID is Excel. A date column that has been through a spreadsheet may arrive as a serial number — 45368 rather than a date — or may have been helpfully reformatted into the locale of the machine that last opened it.
Reduced precision is worth stating deliberately rather than by accident. If you only know the month, write the month; do not write the first of the month. We flag records whose date precision is lower than the rest of the file as FS_DATE_PRECISION_REDUCED — it fired on 38 of the 5,064 already-published records we audited. It is not an error, and GBIF has no code for it; it is something a downstream user would want to know.
And there is a well-known trap on the far side of publication, which is worth knowing before you blame your own file. Publishers have reported repeatedly in GBIF's own community forum — it has a name there, the first of the month/year problem — that a correctly stated reduced-precision date can come back expanded: 2017 served as 2017-01-01, 2017-04 served as 2017-04-01, most often on data arriving through an IPT. If that happens, a day you never claimed to know has been added to your record, and nothing in the validator reports it, because the result is a perfectly valid date.
So do the thing almost nobody does: after you publish, read back what was actually served and compare the dates against the file you sent. A round-trip check is the only thing that catches a defect introduced downstream of your own data — this is the same reason we report on files that had already passed ingestion. It is also why we treat a date's precision as information worth preserving rather than a gap to fill.
2024-03-07, never 2024-3-7.eventDate cell with a solidus rather than in two columns.We confirm a date column by parsing its values, not by trusting its header. If the column is ambiguous we will say so and refuse it rather than pick a reading — and tell you exactly which values made it ambiguous. Free until 1 September 2026, 00:00 UTC · no account · your rows are discarded after the check.
Check the file you have →Measured on a file GBIF had already accepted and served — their validator asks will this load, and it had. Every figure is read from ops/data.json, never typed here. We issue no rating and no seal — each finding names the rule it applied.