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.

Diagram source

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 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.
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 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.
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 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 and read the destination card, then which of your custom tags each site will delete.

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.

Related

• 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
• Which of your custom tags each site will delete
• GEDCOM error messages, decoded