dwcready

What eventDate format does GBIF accept?

Darwin Core · dwc:eventDate · ISO 8601

What you are seeing RECORDED_DATE_INVALID RECORDED_DATE_UNLIKELY

The short answer

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.

The failure that costs people real data is not the one that errors. 01/02/2024 is not ambiguous to a parser — it is ambiguous to everyone, and the parser picks one. Whether that is 1 February or 2 January depends on the locale of whatever wrote the file, which is not recorded anywhere in it. Where the day is 13 or higher the order is recoverable; where it is 12 or lower it is not, and a file that mixes the two conventions cannot be repaired from its own contents at all. We refuse a date column we cannot settle rather than guessing, because a guess here silently moves observations by months.

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.

Before you export

  1. Format the column as text in ISO order before exporting from a spreadsheet, not after.
  2. Write dates zero-padded — 2024-03-07, never 2024-3-7.
  3. Put a range in one eventDate cell with a solidus rather than in two columns.
  4. If some rows are known to the day and others only to the year, leave them at their true precision instead of padding them to 1 January.
See what we can and cannot read in your date column

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, no account, and your records are discarded after the check — we keep the column mapping, never the rows.

Check the file you have →

Why we can say that

5,064records already published to GBIF
0findings in GBIF's vocabulary
4,268findings from ours
31.7%came back clean

We audited a file GBIF had already accepted and served. Their validator answers will this load; these had loaded. Figures read from ops/data.json, not typed into this page. We do not issue a rating of any kind — every finding names the rule it applied and where that rule comes from.

Related