---
title: Why your dates changed when you uploaded
slug: why-your-dates-changed-when-you-uploaded
description: A date that moved is a reading, not a corruption. Separate the day and month swapping places from a chronology that cannot be true.
tools: [date-normaliser, impossible-fact-fixer, gedcom-validator]
difficulty: intermediate
time: 20 minutes
lastChecked: 2026-09-03
published: 2026-09-03T10:30:00+02:00
---

# Why your dates changed when you uploaded

You typed 16 March 1940. The site shows a different day, or a different month, or a year you never entered. Nothing in the tree is missing. The dates moved.

Two unrelated things wear that one complaint, and the repair for one is wrong for the other.

The first is a reading. `02.09.1900` in a file is four digits and two numbers, and nothing in those bytes says which number is the day. A program reading it as day-first gets 2 September. A program reading it as month-first gets 9 February. Both are correct readings of the same bytes. The file lost the answer when it was written.

The second is a chronology. A child born eleven years before the father, a death seventeen years before the birth. No reading fixes those, because the digits are wrong rather than ambiguous.

## What causes the reading to flip

The GEDCOM specification has one date form: day, then a three-letter month, then a four-digit year. `2 SEP 1900`. A month written as a word cannot be misread.

Every exporter that writes `02.09.1900`, `03/04/2011` or `12/05/03` instead has thrown that away. The number in the middle might be a month, and the number at the front might be a day, and there is no rule in the file that settles it. A German export read by a program defaulting to month-first, or a US export read by a program defaulting to day-first, silently produces a different date. It is not a corruption and no importer will warn you, because from the importer's side nothing went wrong.

Three more forms behave the same way:

- `12/05/03` has a two-digit year. 1903, 1803 and 2003 all fit.
- `31 FEB 1946` names a day that does not exist. The month is unambiguous and the date is still not real.
- `FROM 1915 TO 1912` ends before it starts.

A date that will not parse then does something worse than sit there. Any tool computing an age from it produces nonsense, and the nonsense is reported as a chronology error that is not in your tree.

```mermaid
flowchart TD
  S["A date came back different"] --> N["Date Normaliser: read the file"]
  N --> Q{"Which column does the row sit in?"}
  Q -- "to change, confidence 1.00" --> A["Accept: the form changed, the date did not"]
  Q -- "to decide, flagged day or month" --> B["Set Numeric dates read as, then choose per row"]
  Q -- "to decide, flagged no century or day does not exist" --> C["A person has to supply the answer; the file does not hold it"]
  A --> I["Impossible Fact Fixer: run it after the dates are readable"]
  B --> I
  C --> I
  I --> V{"Does a finding survive readable dates?"}
  V -- "yes" --> R["A real chronology error: wrong link or wrong digits"]
  V -- "no" --> D["It was the unreadable date all along"]
```

## The run

Numbers below are from `fixtures/public/ambiguous-dates-synthetic.ged`, a 7-person file holding 15 dates.

1. Open [Date Normaliser](/date-normaliser) and drop the file. The header line reads `15 dates read. 6 are already in the standard form.`
2. Read the summary list under the settings panel. On this file it reads `15 dates read; 6 already canonical`, `4 can be normalised`, `5 need a decision and are not changed until you accept them`, `month names in English, French`.
3. Read the section title above the table: `4 to change, 5 to decide`.
4. Set **Numeric dates read as** to `day / month / year` if the file came from Europe, or `month / day / year` if it came from the United States. This is the setting that decides every ambiguous row, and the URL records it so a run is reproducible from a link.
5. Find the row whose **In the file** column reads `02.09.1900`. With day / month / year the **Proposed** column reads `2 SEP 1900`. Switch the setting to month / day / year and the same row reads `9 FEB 1900`. Confidence stays 0.50 either way, and the Why column lists both readings: `2 SEP 1900 if 02 is the day` and `9 FEB 1900 if 02 is the month`.
![The Date Normaliser findings table on ambiguous-dates-synthetic.ged: nine rows with their proposals, the day-or-month, day-does-not-exist, ends-before-it-starts and no-century flags, and a confidence on each.](/kb/shots/why-your-dates-changed-when-you-uploaded-normaliser.jpg)
6. Read the rows with confidence 1.00. On this file there are four: `16.03.1940` to `16 MAR 1940`, `21-Nov-1877` to `21 NOV 1877`, `1866-04-07` to `7 APR 1866`, and `abt. 4 juillet 1901` to `ABT 4 JUL 1901` at 0.97. Those change the writing, not the date, and the reading is settled by the digits themselves.
7. Leave **Keep the original text in the file** ticked. The original string is written beside every date the tool changes, so the change is reversible by reading rather than by undo.
8. Untick any row you disagree with, then read **Write the file** at the bottom. On this fixture it reads `4 dates rewritten, 4 originals kept in the file, 1 KB` and offers **ambiguous-dates-synthetic.dates.ged**, **ledger JSON** and **patch JSON**.
9. Open [Impossible Fact Fixer](/impossible-fact-fixer) and drop the same file. The header line reads `7 people, 1 families, 15 dated events checked`, and the two count tiles read `impossible 3` and `improbable 0`.
10. Click the **impossible** count to filter. One row reads `Czeslaw Baranowski (@I7@): at least 1957 years 27 days from BIRT 12/05/03 to DEAT 1961`. That is not a person who lived 1,957 years. It is the two-digit year from step 5 being read as year 3.
11. Read the other two rows. Both are `child-before-parent-birth` on `@I4@`: born 11 years 228 days before the father, and 15 years 331 days before the mother. Those survive any reading of the digits. That is a real error in the tree. **Rules that fired** above the table names both rules and their validator codes, `child-before-parent-birth` and `age-over-120`.
![The Impossible Fact Fixer on the same file: an impossible count of 3 against an improbable count of 0, the two rules that fired, and three findings each showing the arithmetic behind it.](/kb/shots/why-your-dates-changed-when-you-uploaded-impossible.jpg)
12. Click a finding to read **Fixes on offer**. Every row on this file shows `0` in the Fixes column, and the panel explains why: the `child-before-parent-birth` row on `@I4@` reads `8 candidate dates tested; every one traded this contradiction for another, so none is offered. The error is more likely a wrong link or a missing generation than a mistyped digit.` On a file where a digit is transposed the panel offers the edit instead: `fixtures/public/impossible-facts-synthetic.ged` returns `BIRT 1897 to 1879` at 85% with the before and after lines shown.
13. When the dates are right and the rule fired anyway, type the reason in the box under **Or keep the dates** and press **Reviewed, keep the dates**. That writes a determination on the record, so the next program reads your decision instead of raising the same finding.

## What to check when it worked

- Date Normaliser reports 0 in the `to decide` half of the section title, or every remaining row is one you looked at and left alone.
- Every accepted row carries confidence 1.00, or you set **Numeric dates read as** deliberately for the ones at 0.50.
- **Write the file** reports as many originals kept as dates rewritten. On this fixture that is 4 and 4, each kept as a NOTE beside the date.
- Impossible Fact Fixer, run again on the normalised file, shows fewer impossible findings. Any that remain are chronology, not syntax.
- [GEDCOM Validator](/gedcom-validator) on the normalised file reports no `date-unparsed` and no `date-nonstandard` codes.

## What to do when it did not

**A row still reads `no proposal`.** The file does not hold the answer. `12/05/03` could be 1903, 1803 or 2003, and the tool refuses to pick. Find the person in a record and type the year.

**The site changed the dates again after you uploaded the normalised file.** Then it was not reading your dates, it was rewriting them. Run [Dialect Report](/gedcom-dialect-report) and read the destination card, then [which of your custom tags each site will delete](/how-to/what-each-site-deletes-from-your-gedcom).

**An impossible finding has no fix on offer and the dates look right.** The link is wrong, not the date. A child attached to the wrong family reads as a chronology error. Check the parents in the **Family around this finding** panel below the finding.

**You are moving to GEDCOM 7.0 and the dates changed shape again.** 7.0 drops the 1750/51 dual-year form and the `(interpreted)` phrase syntax. Set **Write dates for** to `7.0` before downloading, and read [how to convert GEDCOM 5.5.1 to 7.0, and what does not survive](/how-to/convert-gedcom-5-5-1-to-7-0-and-what-does-not-survive).

## Related

- [How to check a GEDCOM before you import it anywhere](/how-to/check-a-gedcom-before-you-import-it-anywhere)
- [How to convert GEDCOM 5.5.1 to 7.0, and what does not survive](/how-to/convert-gedcom-5-5-1-to-7-0-and-what-does-not-survive)
- [Which of your custom tags each site will delete](/how-to/what-each-site-deletes-from-your-gedcom)
- [GEDCOM error messages, decoded](/how-to/decode-gedcom-error-messages)