What a parser does with “Summer 2019”, and why 03/04/2024 is a coin flip

A date is not validated. It is recognised, or it is not

Haisleaf stores a date as the parts the author actually chose — a year, optionally a month — and reads text into that shape when importing a resume. So there is a list of patterns it recognises, and everything outside that list is kept verbatim as text rather than being forced into a shape it does not fit.

A month name may be abbreviated or written out, with or without a full stop — Sept. 2021 reads the same as September 2021. That branch is generous because it can afford to be: there is only one thing a month name can mean.

Why an unreadable date is quiet rather than loud

Summer 2019, Ongoing, 2019–present (contract) — these are not malformed. They are perfectly clear to a person and carry no month, or no endpoint, or a parenthetical no pattern anticipates. There is nothing to raise an error about.

So the date survives as text and stops participating in anything arithmetic. It cannot be sorted, cannot be compared to another date, and cannot contribute to a duration. If a recruiter filters for candidates with three years in a role, or sorts by most recent position, a résumé whose dates are all text is not wrong in that list. It is absent from it.

Our own reader keeps the text exactly as written and renders it back unchanged, because the alternative is worse. Its rule is the one we would give anybody building this: a wrong guess is worse than an unparsed string, since a guess silently reformats a date the author deliberately chose, and then persists.

The coin flip nobody mentions

03/04/2024 is either 3 April or 4 March. Both are real dates. Both parse. No error is possible, because nothing about the string is wrong — the information that would settle it was never written down.

Inside a Haisleaf document the question has an answer: the document declares its own date convention, so a stored date is read through the format its author chose. That is a fact about a document we control. An imported file declares nothing, so our importer assumes day-first — and an applicant tracking system receiving your PDF is in exactly the same position. It picks a convention, usually its own locale’s, and it picks silently.

Which means an all-numeric date where both numbers are twelve or under is a coin flip on every system that reads it. The failure is a role that appears to have started eleven months earlier or later than it did — plausible, unflagged, and invisible to you.

What to write instead

1. A month name and a four-digit year. Mar 2021 – Jun 2024. There is no locale in which that means two different things, and no parser that needs to guess. This is the entire recommendation; everything below is a corollary.
2. Avoid all-numeric dates unless they are ISO — 2024-03 is unambiguous by definition. 03/2024 is fine too, since only one reading fits. It is the three-part numeric form that is the trap.
3. Year-only is a legitimate choice, not a failure. It reads cleanly and says less. Use it deliberately — for older roles, or where months would imply a precision you would rather not invite — and not as a way to blur a gap, which a reader notices.
4. Say “Present”, not a synonym. Ongoing, Current and To date mean the same thing to a person. “Present” is the convention, and a convention is the thing somebody writing a parser thinks to write a case for.
5. Keep the parenthetical out of the date. 2019–present (contract) puts a word inside a field that is otherwise arithmetic. Put “contract” in the role, where it reads better anyway.

Haisleaf writes month-and-year dates by default for this reason, and an imported date it cannot read is kept exactly as you wrote it rather than being quietly reshaped. The rest of what a parser keeps and drops is in what an applicant tracking system actually reads.