Feature request: 2 dates per fact and person

After adding to my data over many years, it would be really helpful to see two dates for each fact: the date it was first added and the most recent date it was modified. For example, if I have 2 birth dates for a person and can’t remember how that came about, if I knew that one was added when I was just starting out and the other just 2 years ago, that would give me a clue as to how to weight them. But if the older one was last modified 6 months ago, that could change my outlook.

The same holds true for the person overall. We already have “Date edited” in the footer of the person window. If we could add “Date inserted” that would be informative.

For searches, we already have date edited for the person, so date inserted would be a logical addition. For facts, we have the date subfield which is the date of the fact. Perhaps we could have meta-fields for date inserted and date edited to find, say, births that were edited in the past month.

I can’t say that I have ever taken much notice of the Date edited in the footer of the person window but I just wondered what happens to these if you do a complete ‘drag+drop’ as is often suggested to ameliorate some database corruption, or even to restore from a backup. Do these edit dates remain the same or all change to the date when such action was taken?

As of RM8, the database structure was revised to add the field UTCModDate to every table which appears to hold the date/time that a record was added to the table or subsequently modified. There is no, say, UTCAddDate that permanently stores the date the record was first created.

The UI does not expose UTCModDate nor do we know how they may factor into the Person’s Date Last Edited.

I’m unsure how much value there may be in having this level of granularity in the UI. It’s not something I would want to see taking up screen space in standard views so it would need to be a viewing option or popout.

There are other existing features that tease possibilties that I would like to see development effort on:
Fact Proven/Disproven/Disputed… should be made available and exploited in reports, views, queries, filters…
Citation Quality… likewise

Note in your source citation when you found this although this info is already part of source info from ancestry.

They remain the same whether it’s a complete or selective drag’n’drop. Supported by the GEDCOM standard tag CHAN:

0 @I1602@ INDI
1 NAME Clifford Hartley /Greenaway/
2 GIVN Clifford Hartley
2 SURN Greenaway
1 SEX M
1 _UID BE87F355451F43F1A91D343A7BDCCB65E0F4
1 CHAN
2 DATE 31 MAR 2010
1 _COLOR 7
1 Like

The date a change was made doesn’t necessarily equate to what information is more accurate or not. It’s the source itself that will weigh in on that determination. The Research Note field of the source citation is where you can note what data you extracted and entered into RM. In the Detail Comment field enter any additional information, date of entry, anything you wish. Going forward add that documentation so you can tell where the information came from.

1 Like

Agreed that change date is not about accuracy. This is for a scenario where I added burial information to a bunch of people 3 months ago, and suddenly realized that I may have pasted the wrong source citation for some of them. I don’t remember exactly which people it was, but I know I did a batch in a certain time frame. If I could search for burial facts added in that date range, it would help me zero in.

If you did nothing to those persons since the burial fact was added, the Date Edited will be the date that fact was added. You might do a criterion group: Mark Date Edited for the range and unmark those for which burial does not exist. Won’t be exclusively the ones you want but will capture some.