## 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

```text
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