* Updating existing FH records with data from CSV

[Mark1834]

Perhaps broaden it to look at the time frames of available facts? This was a quick tweak to an existing script, but agree that the final version should look more systematically at what is available.

[tatewise]

Yes, Normal Time Frame is a good idea, except it would exclude Christening (adult).
Presumably, the fact with the earliest date would take precedence.

[AdrianBruce]

...
The Death should be derived from Burial and if none then Cremation and lastly Probate.

On the other hand, personally I'd take a Cremation date first then a Burial on the basis that if both are present, then the Burial is likely to be the interment of the ashes, which can be some time after the cremation itself. Years later, in one instance that I have. Happy to leave probate as 3rd choice.

[NickiP]

Ooh I'm glad someone mentioned Cremations and death dates as it had completely slipped my mind.

Just amended the plugin having found I had about 15 cremations with no death date so they now have death dates in the export.

[tatewise]

Adrian, if the strategy uses the earliest fact with a Normal Time Frame of Post-Death that should give the best Death year.
That would not only cater for Burial, Cremation & Probate but any other custom Post-Death fact, whichever is earliest and of course requires a Date.

[AdrianBruce]

Adrian, if the strategy uses the earliest fact with a Normal Time Frame of Post-Death that should give the best Death year. ...

Sounds good to me.

[Mark1834]

Yes, exactly how I end up doing it will depend on the scope of the listed data. If it is just defined fields (CREM, BURI, PROB), finding the earliest of those is probably simplest. If it is more general, it will need to be the earliest post-death event.

[tatewise]

Mark, if the plugin loops through all facts then the first one it finds with both Normal Time Frame = Post-Death and a Date is the one to use to synthesise a Death event. Similarly, the first fact with both Normal Time Frame = Shortly After Birth and a Date is the one to use to synthesise a Birth event. That avoids any special cases with specific code.
If the user has restricted the set of facts, then looping through all facts imposes little overhead.
I find that using the same script for all cases avoids unexpected glitches.

[tatewise]

I have moved this thread to the Importing and Exporting forum that seems more appropriate.

The Export Gedcom File plugin new features (19799) thread has a prototype plugin ZIP file supporting the synthesis of missing Birth/Death events feature needed for products offering DNA analysis and requiring those two events.