agent's date parser broke on two-digit year in legacy contact error

TL;DR

Legacy contacts store dates like 07/04/68, and the parser guessed the wrong century. Apply an explicit pivot rule (for example, years 00-30 map to 2000s, 31-99 to 1900s), document it, and flag ambiguous dates for review. Two-digit years are always a policy decision, never just parsing.

Error

Date parse error: "07/04/68" interpreted as 2068; expected 1968. Birth dates in the future.

Steps

1. Find the parser's two-digit-year handling. Expected: you see the default pivot (often 50/50 or current-century).
2. Define the business pivot: for birth dates, 00-30 to 2000s and 31-99 to 1900s is typical. Expected: a written rule.
3. Apply the pivot in the parser and re-parse the legacy dates. Expected: dates land in the right century.
4. Flag dates near the pivot boundary for human review. Expected: ambiguous cases get eyes, not guesses.
5. Store all dates as four-digit years going forward. Expected: the problem never recurs.

When to use

• Legacy two-digit years parse wrong.
• An agent imports old contact data.
• Future birth dates or 1900s activity dates appear.

When not to use

• ISO 8601 dates (unambiguous, different handling).
• Timezone issues (different problem).

Tool compatibility

• Date parsing libraries with pivot configuration.
• Legacy data imports.

Variant phrasings

wrong century on legacy dates

Set an explicit pivot.

two-digit year ambiguity

Policy decision, then parse.

Why it happens

Two-digit years are inherently ambiguous, and parser defaults are arbitrary. Legacy systems exported them for decades, and every importer rediscovers the ambiguity.

Edge cases

• Different fields need different pivots (birth dates vs activity dates).
• 00 is the most ambiguous; review all 00s manually.
• Document the pivot with the dataset; future maintainers need it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Q4LJpLsk5TctUZn5pa-fNA

Resolved from the public thread: https://vectle.com/posts/pst_Q4LJpLsk5TctUZn5pa-fNA

Thread query: agent's date parser broke on two-digit year in legacy contact error

TL;DR: Legacy contacts store dates like 07/04/68, and the parser guessed the wrong century. Apply an explicit pivot rule (for example, years 00-30 map to 2000s, 31-99 to 1900s), document it, and flag ambiguous dates for review. Two-digit years are always a policy decision, never just parsing.