Ahnenblattportal

Da ich einige Datumseingaben - für mich - neu entdeckt habe, gab es auch hierzu einen kleinen Feldversuch
Nachfolgende Fehler / Ungereimtheiten glaube ich beim Import entdeckt zu haben. Der Vollständigkeit halber zitiere ich auch die Testergebnisse für den Export (welches Datumsformat könnte man noch testen?), die durchweg gut aussehen und die "guten" Werte beim Import, damit man die Ergebnisse auch vergleichen kann.
Zum Schluss noch eine kleine Übersicht, wie Ahnenblatt mit falschen Daten beim Export umgeht und was mit den "außergewöhnlichen" Daten geschieht.
Marcus

Ahnenblatt: Export ins Gedcom-Format

31.12.1899 ---> 31 DEC 1899

??.02.1921 ---> FEB 1921
__.02.2001 ---> FEB 2001

??.??.1922 ---> 1922
__.__.2002 ---> 2002

vor 1923 ---> BEF 1923
nach 2003 ---> AFT 2003

vor ??.12.1923 ---> BEF DEC 1923
vor 31.12.1923 ---> BEF 31 DEC 1923
nach ??.04.1943 ---> AFT APR 1943
nach 01.01.2003 ---> AFT 1 JAN 2003

berechnet 1924 ---> CAL 1924
errechnet 2004 ---> CAL 2004

geschätzt 1925 ---> EST 1925
etwa 2005 ---> ABT 2005
ca. 1927 ---> ABT 1927
um 2007 ---> ABT 2007

von 1926 ---> FROM 1926
bis 2006 ---> TO 2006
ab 2006 ---> FROM 2006

von 1946 bis 1966 ---> FROM 1946 TO 1966
zwischen 1926 und 1927 ---> BET 1926 AND 1927

von ??.01.1967 bis __.12.1968 ---> FROM JAN 1967 TO DEC 1968
von 01.01.1970 bis 31.12.1971 ---> FROM 1 JAN 1970 TO 31 DEC 1971
zwischen __.06.1927 und ??.12.1927 ---> BET JUN 1927 AND DEC 1927
zwischen 01.01.2006 und 30.06.2006 ---> BET 1 JAN 2006 AND 30 JUN 2006

Ahnenblatt: Import aus einer Gedcom-Datei (problematische Fälle)

BEF DEC 1923 ---> 12.1923
AFT APR 1943 ---> 04.1943
BEF 31 DEC 1923 ---> 31.12.1923
AFT 1 JAN 2003 ---> 01.01.2003
"vor" und "nach" werden unterschlagen.

FROM JAN 1967 TO DEC 1968 ---> 01.1967 12.1968
FROM 1 JAN 1970 TO 31 DEC 1971 ---> 01.01.1970 31.12.1971
BET JUN 1927 AND DEC 1927 ---> 06.1927 12.1927
BET 1 JAN 2006 AND 30 JUN 2006 ---> 01.01.2006 30.06.2006
- Keine Unterscheidung zwischen "von bis" und "zwischen und". Werden beim Export wieder nur als Textfelder behandelt.

29 FEB 1900 ---> 30.12.1899
31 APR 1901 ---> 30.12.1899
- Nicht existierende Daten werden auf ein anderes Datum gesetzt: Ein Tag vorm frühesten Datum in der Datei?

Ahnenblatt: Import aus einer Gedcom-Datei - unproblematisches

31 DEC 2000 ---> 31.12.2000
29 FEB 1924 ---> 29.02.1924
29 FEB 2000 ---> 29.02.2000

FEB 1921 ---> 02.1921
1922 ---> 1922

BEF 1923 ---> vor 1923
AFT 2003 ---> nach 2003

CAL 1924 ---> errechnet 1924
EST 1925 ---> geschätzt 1925
ABT 2005 ---> um 2005

FROM 1926 ---> von 1926
TO 2006 ---> bis 2006
FROM 1946 TO 1966 ---> von 1946 bis 1966
BET 1926 AND 1927 ---> zwischen 1926 und 1927

Ahnenblatt: Umgang mit falschen Daten / und "gerade noch korrekten"

29.02.1924 ---> 29 FEB 1924
29.02.2000 ---> 29 FEB 2000

29.02.1900 ---> 29 FEB 1900
31.04.1901 ---> 31 APR 1901
- Gibt es nicht, aber die Einzelwerte (Tag und Monat) sind möglich).

32.01.1901 ---> 32.01.1901
31.13.2000 ---> 31.13.2000
- Daten die im Tag oder Monat zu groß sind (>31 und/oer >12), werden als Text exportiert.

Ahnenblatt: Noch nicht umgesetzte Gedcom-Tags beim Export?

verstorben ---> verstorben
verstorben 1928 ---> verstorben 1928
Früh gestorben ---> Früh gestorben
Früh gestorben 1929 ---> Früh gestorben 1929
Tot geboren ---> Tot geboren
Totgeburt ---> Totgeburt

-Hierfür gibt es wohl Gedcom-Tags, die in Ahnenblatt allerdings nicht umgesetzt sind?
Welche es genau gibt und wie deren Umsetzunge aussehen müsste / sollte, muss ich allerdings noch prüfen Dies sind die Formate aus dem alten Knowledge Base Eintrag und leicht erweiterte.


Zusammenfassend kann man sagen, dass es noch Fehler beim Import gibt:

• Wenn mehr als das Jahr angegeben ist bei
  • Before
  • After
  • From To
  • Between And
• Nicht existierende Daten werden auf ein völlig Anderes umgesetzt

Und beim Export:

• Ist das Datum in den einzelnen Werten für Tag und Monat möglich wird es exportiert, auch wenn es das Datum nicht geben kann.
• Unmögliche Daten werden als text exportiert

Beides (beim Export) sollte ggf. einfach über die Plausi abgefangen werden?! Dann blieben nur noch die Importfunktionen

Guten Tag
Antwort auf die schnelle:
Schau bitte mal im Betatest Personeneditierfeld. Dort hatte Bjew diese Problematik schon festgestellt, als meine Frau Isabelle für Scheidung das erlaubte Gedcomdatum "zwischen und" erwähnte

Hier die Abschlußbeiträge daraus:

bjew hat geschrieben:Es geht dabei nicht darum, was AB machen sollte, sondern darum, was es tut. Wie wir erfahren haben, gibt es tatsächlich Anwender, die rein mit dem ged-Format arbeiten.

Hugo hat geschrieben:Wie wir aber schon von Dirk erfahren haben (Geschwister der Spitzenahnen) ist Gedcom immer nur eine halbherzige Speichermethode.

bjew hat geschrieben:Wird doch nicht etwa wieder eine Systemabhängigkeit sein?!?!?!?

Hugo hat geschrieben:Das glaube ich nicht. Habe es auf Win98 und XP Home probiert.
Ich glaube eher, das wir doch einen Unterschied im Ablauf gemacht haben

Hugo hat geschrieben:Ich muß mich entschuldigen

Ich war derjenige mit der "Falscheingabe" bezüglich "zwischen und" im Datum.
Werden nur Jahreszahlen JJJJ eingegeben (wie ich es aus Faulheit getan hatte) funktioniert bei "speichern unter Gedcom" alles einwandfrei

Sobald jedoch das komplette Datum TT.MM.JJJJ tritt Bernhards Fehler auch bei mir auf.

Gruß Hugo

Guten Tag
Ich hatte mich damals, bezüglich erlaubte Begriffe im Datum nach Gedcom, nur um Den Export gekümmert und nicht um den Import.
Die erlaubten Begriffe hatte ich über Gen Wiki in Gedcom 5.5.1 gefunden (120 Seiten in englisch)

Dabei hatte ich auch bei diversen Test-Programmen mir den Export angeschaut.
Ahnenblatt kann von allen die meisten Datumsformate korrekt exportieren

Eine Gedcom-Datei, die wir erhalten, ist meistens aus einem anderen Programm.
Denn sonst besteht die Möglichkeit die Datei als xy.ahn zu bekommen und dann gebe es eh keine Probleme.
Also betrachte ich Gedcom immer mit Vorsicht. Zumal es extreme Einschränkungen darin gibt.
Wenn z.B. von einer vierstelligen Jahreszahl eine fehlt, ist das nach Gedcom nicht eingebbar.
Gedcom läßt nur zu, TT oder TT.MM durch ? zu ersetzen. Die Jahreszahl muß immer komplett sein

Zum Glück sind diese Einschränkungen in Ahnenblatt nicht, da die Datumsfelder Freitextfelder sind.
Dort können reinschreiben, was wir wollen.
Das ist ein nicht zu unterschätzendes Plus für Ahnenblatt

Außerdem Steht Gedcom 6 vor der Tür!
Also, warum so viel Gedanken um Gedcom 5.5 machen.
Ein Gedcom Datenaustausch war, ist und bleibt immer problematisch

Nun zu den vorgehenden Beiträgen:

Marcus hat geschrieben:Ahnenblatt: Noch nicht umgesetzte Gedcom-Tags beim Export?
verstorben ---> verstorben
Früh gestorben ---> Früh gestorben
Tot geboren ---> Tot geboren
Totgeburt ---> Totgeburt

Nach Gedcom müßte es heißen:
verstorben ---> DECEASED
Früh gestorben ---> DEAD
Tot geboren ---> STILLBORN
Totgeburt ---> STILLBORN

Marcus hat geschrieben:Zusammenfassend kann man sagen, dass es noch Fehler beim Import gibt:

* Wenn mehr als das Jahr angegeben ist bei
o Before
o After
o From To
o Between And

Marcus, was meinst Du mit "Between And"
Ich kenne nur "BET AND"

Gruß Hugo

Vorweg: Ich kann Hugos Lob zustimmen, trotzdem halte ich die paar kleinen Fehler für unnötig und leicht korrigierbar. Da es sich um mehr Werte handelt als in der anderen Diskussion betrachtet, hatte ich hier die ausführliche Liste gepostet.
Marcus

Hugo hat geschrieben:
Ahnenblatt kann von allen die meisten Datumsformate korrekt exportieren

Ich würde sogar soweit gehen und behaupten dass es alle als Datum erkannten Werte richtig exportiert. Wenn etwas nicht korrekt exportiert wird, liegt das derzeit höchstens noch daran, dass man etwas als Datum eizugeben meint, dass Ahnenblatt nicht als Fragment eines solchen erkennt. Der 01.??.2006 wäre so ein Beispielt (so weit ich mich erinnere). Wenn man sich hier beim Monat nicht mehr sicher war, nützt es auch nix den Tag zu wissen - dies wird als Text exportiert.

Außerdem Steht Gedcom 6 vor der Tür!
Also, warum so viel Gedanken um Gedcom 5.5 machen.
Ein Gedcom Datenaustausch war, ist und bleibt immer problematisch

Einmal weiß man nicht wann die Spezifikation geändert wird und außerdem werden elementare Datumsbeschreibungen auch darin nicht geändert werden. Es geht in meinen Beispielen ja nur um Importe klar erkennbarer Daten, die Ahnenblatt ja auch korrekt exportiert.

Marcus, was meinst Du mit "Between And"
Ich kenne nur "BET AND"

Natürlich meine ich die beiden! Wollte das ganze nur ausschreiben, damit man gleich erkennt worum es geht Gemeint sind ja auch BEF und AFT und nicht Before und After ...
Marcus

Guten Tag
Den Import habe ich zwar noch nicht mit Version 135f probiert, aber wahrscheinlich wird das gleiche passieren.
Dirk hatte (glaube ich) zuletzt bei Version 133 im Gedcom-Teil programmiert.

Da es sich aus meiner Sicht um ein altes Problem handelt, werde ich es heute oder morgen mal mit allen Beiträgen in die Wunschliste übernehmen

Aber vorher möchte ich gerne auch mal wieder ein wenig testen.
Dafür möchte ich mir aber erstmal eine große Testdatei erstellen, die erlaubte und nicht erlaubte Gedcom-Formate enthält
Gruß Hugo

Guten Tag
Und wenn ich jetzt dieses Thema sprenge

Bevor ich mit dem Export und Importtest beginne, fällt jemand noch ein Datumszusatz nach Gedcom ein

Gruß Hugo

Testfamilie für Ex und Import

Prüfling >> Datumsformat >> wäre nach Gedcom

Kind 01 >> 21.10.1801 >> 21 OCT 1801
Kind 02 >> ??.10.1802 >> OCT 1802
Kind 03 >> __.10.1803 >> OCT 1803
Kind 04 >> ??.??.1804 >> 1804
Kind 05 >> __.__.1805 >> 1805

Kind 06 >> berechnet 1806 >> CAL 1806
Kind 07 >> berechnet 10.1807 >> CAL OCT 1807
Kind 08 >> berechnet 21.10.1808 >> CAL 21 OCT 1808

Kind 09 >> errechnet 1809 >> CAL 1809
Kind 10 >> errechnet 10.1810 >> CAL OCT 1810
Kind 11 >> errechnet 21.10.1821 >> CAL 21 OCT 1821

Kind 12 >> geschätzt 1812 >> EST 1812
Kind 13 >> geschätzt 10.1813 >> EST OCT 1813
Kind 14 >> geschätzt 21.10.1814 >> EST 21 OCT 1814

Kind 15 >> vor 1815 >> BEF 1815
Kind 16 >> vor 10.1816 >> BEF OCT 1816
Kind 17 >> vor 21.10.1817 >> BEF 21 OCT 1817

Kind 18 >> nach 1818 >> AFT 1818
Kind 19 >> nach 10.1819 >> AFT OCT 1819
Kind 20 >> nach 21.10.1820 >> AFT 21 OCT 1820

Kind 21 >> ab 1821 >> FROM 1821
Kind 22 >> ab 10.1822 >> FROM OCT 1822
Kind 23 >> ab 21.10.1823 >> FROM 21 OCT 1823

Kind 24 >> von 1824 >> FROM 1824
Kind 25 >> von 10.1825 >> FROM OCT 1825
Kind 26 >> von 21.10.1826 >> FROM 21 OCT 1826

Kind 27 >> bis 1827 >> TO 1827
Kind 28 >> bis 10.1828 >> TO OCT 1828
Kind 29 >> bis 21.10.1829 >> TO 21 OCT 1829

Kind 30 >> etwa 1830 >> ABT 1830
Kind 31 >> etwa 10.1831 >> ABT OCT 1831
Kind 32 >> etwa 21.10.1832 >> ABT 21 OCT 1832

Kind 33 >> ca 1833 >> ABT 1833
Kind 34 >> ca 10.1834 >> ABT OCT 1834
Kind 35 >> ca 21.10.1835 >> ABT 21 OCT 1835

Kind 36 >> um 1836 >> ABT 1836
Kind 37 >> um 10.1837 >> ABT OCT 1837
Kind 38 >> um 21.10.1838 >> ABT 21 OCT 1838

Kind 39 >> von 1839 bis 1840 >> FROM 1839 TO 1840
Kind 40 >> von 10.1840 bis 10.1841 >> FROM OCT 1840 TO OCT 1841
Kind 41 >> von 21.10.1841 bis 21.10.1842 >> FROM 21 OCT 1841 TO 21 OCT 1842

Kind 42 >> zwischen 1842 und 1843 > BET 1842 AND 1843
Kind 43 >> zwischen 10.1843 und 10.1844 >> BET OCT 1843 AND OCT 1844
Kind 44 >> zwischen 21.10.1844 und 10.10.1845 >> BET 21 OCT 1844 AND 21 OCT 1845

Kind 45 >> verstorben >> DECEASED
Kind 46 >> verstorben 1846 >> DECEASED 1846
Kind 47 >> verstorben 10.1847 > DECEASED OCT 1847
Kind 48 >> verstorben 21.10.1848 >> DECEASED 21 OCT 1848

Kind 49 >> Früh gestorben >> DEAD
Kind 50 >> Früh gestorben 1850 >> DEAD 1850
Kind 51 >> Früh gestorben 10.1851 >> DEAD OCT 1851
Kind 52 >> Früh gestorben 21.10.1852 >> DEAD 21 OCT 1852

Kind 53 >> Tot geboren >> STILLBORN
Kind 54 >> Tot geboren 1854 >> STILLBORN 1854
Kind 55 >> Tot geboren 10.1855 >> STILLBORN OCT 1855
Kind 56 >> Tot geboren 21.10.1856 >> STILLBORN 21 OCT 1856

Nachtrag von Hugo
Meine Datums-Testfamilie wächst und wächst

Hier eine Aufstellung der neuen zusätzlichen Testkinder

ungewöhnliche Datumsangaben
Kind 71 >> 29.02.1900
Kind 72 >> 29.02.1872
Kind 73 >> 29.02.1873
Kind 74 >> 30.02.1874
Kind 75 >> 31.02.1875
Kind 76 >> 31.04.1876
Kind 77 >> 31.06.1876
Kind 78 >> 31.09.1877
Kind 79 >> 31.11.1878

Re-Import von Gedcom Datumszusätzen
Kind 81 >> DECEASED
Kind 82 >> DECEASED 1882
Kind 83 >> DECEASED OCT 1883
Kind 84 >> DECEASED 21 OCT 1884

Kind 85 >> DEAD
Kind 86 >> DEAD 1886
Kind 87 >> DEAD OCT 1887
Kind 88 >> DEAD 21 OCT 1888

Kind 89 >> CHILD
Kind 90 >> CHILD 1890
Kind 91 >> CHILD OCT 1891
Kind 92 >> CHILD 21 OCT 1892

Kind 93 >> INFANT
Kind 94 >> INFANT 1894
Kind 95 >> INFANT OCT 1895
Kind 96 >> INFANT 21 OCT 1896

Kind 97 >> STILLBORN
Kind 98 >> STILLBORN 1898
Kind 99 >> STILLBORN OCT 1899
Kind 100 >> STILLBORN 21 OCT 1900

Hallo,
selbstverständlich sollten auch die Gedcom-konformen Eingaben, wie bei dir auf der rechten Seite richtig übernommen/ergänzt werden. Aber auch die Gross-/Kleinschreibung ignoriert werden (insbesondere Import).

Hab jetzt noch nicht nachgesehen, werden die Monatsnamen auch verstanden (Export, bei Import ist Monatsnummer durchaus zulässig)?

Und ganz wichtig ist eben, dass Datumsangeben, nicht wie bisher, verkürzt werden
(Ranges etc), <TAG> TT.MM.JJJj auf <TAG> JJJJ

Guten Tag
Bis Kind 44 werden alle angegebenen Formate nach Gedcom übernommen

Bernhard sein Gedanke, statt Monatszahl auch das Monatswort zu übernehmen, habe ich nicht getestet, da es nach Gedcom nicht zulässig ist.

@Bernhard: Ist aber eine guter Ansatzpunkt. Nur was willst Du testen?
Einige kürzen den Monat ab, andere schreiben ihn aus.

Wird als Text übernommen
Kind 45 >> verstorben >> DECEASED
Kind 46 >> verstorben 1846 >> DECEASED 1846
Kind 47 >> verstorben 10.1847 > DECEASED OCT 1847
Kind 48 >> verstorben 21.10.1848 >> DECEASED 21 OCT 1848

Wird als Text übernommen (unklar, da keine einheitliche Definition gefunden)
Kind 49 >> Früh gestorben >> DEAD
Kind 50 >> Früh gestorben 1850 >> DEAD 1850
Kind 51 >> Früh gestorben 10.1851 >> DEAD OCT 1851
Kind 52 >> Früh gestorben 21.10.1852 >> DEAD 21 OCT 1852

Wird als Text übernommen
Kind 53 >> Tot geboren >> STILLBORN
Kind 54 >> Tot geboren 1854 >> STILLBORN 1854
Kind 55 >> Tot geboren 10.1855 >> STILLBORN OCT 1855
Kind 56 >> Tot geboren 21.10.1856 >> STILLBORN 21 OCT 1856

Nach Gedcom muß die Jahreszahl komplett sein ( ? sind nicht erlaubt )
? dürfen laut Gedcom nicht mitten im Datum stehen.
? (bei Ahnenblatt auch _ ) werden von Gedcom nicht übernommen (nicht zulässig, daher wird es von Ahnenblatt ignoriert)

Derzeit gibt es in Ahnenblatt (egal ob 135 oder 2.0 Beta) Importprobleme.
Sobald Monat oder Tag/Monat mit angegeben sind, werden die Datumszusätze nicht importiert.

Einen Bericht mit einer Tabelle dazu sende ich an Dirk.
Die Tabelle kann ich aber nicht hier reinstellen, da sie einfach zu breit ist.
Gruß Hugo

Hallo Hugo,

Hugo hat geschrieben: Bernhard sein Gedanke, statt Monatszahl auch das Monatswort zu übernehmen, habe ich nicht getestet, da es nach Gedcom nicht zulässig ist.

Vorsicht, bei "verstorben 21.10.1848 >> DECEASED 21 OCT 1848 " ist auf der Gedcom-Seite doch ein Monatsname, keine Monatsnummer, einfach in der übl(ich)en amerikanischen Notation, genau das meinte ich auf der AB-Seite, also zum Bleistift: "verstorben 21. Oktober 1848"

Hugo hat geschrieben: @Bernhard: Ist aber eine guter Ansatzpunkt. Nur was willst Du testen?
Einige kürzen den Monat ab, andere schreiben ihn aus.

In diesem Falle wäre wohl korrekt, sowohl die normierte Abkürzung, als auch die ausgeschriebene Form zu akzeptieren - kein grosser Aufwand !!!!
Was mit den landesspezifischen Formen, z.B. Jänner, Feber ... in Ösikand und den Entsprechungen in der Schweiz ist, ist was anderes. Rückübersetzen von Gedcom -> Ahnenblatt würde ich die Monatsnummer ( 01 .... 12 ) vorschlagen, ausser irgendjemand plädiert dringen für eine Option für "Monatsnamen"

Guten Tag

bjew hat geschrieben:Vorsicht, bei "verstorben 21.10.1848 >> DECEASED 21 OCT 1848 " ist auf der Gedcom-Seite doch ein Monatsname, keine Monatsnummer, einfach in der übl(ich)en amerikanischen Notation, genau das meinte ich auf der AB-Seite, also zum Bleistift: "verstorben 21. Oktober 1848"

Die Rückübersetzung findet in Ahnenblatt bei dem Beispiel genau so statt, wie Bernhard es geschrieben hat, da Ahnenblatt "verstorben" als Text in die Gedcom Datei schreibt.
Würde ich aber in Ahnenblatt 21.10.1848 schreiben, wäre es nach Gedcom 21 OCT 1848 Der Re-Import ergibt dann 21.10.1848

bjew hat geschrieben:In diesem Falle wäre wohl korrekt, sowohl die normierte Abkürzung, als auch die ausgeschriebene Form zu akzeptieren - kein grosser Aufwand !!!!
Was mit den landesspezifischen Formen, z.B. Jänner, Feber ... in Ösikand und den Entsprechungen in der Schweiz ist, ist was anderes. Rückübersetzen von Gedcom -> Ahnenblatt würde ich die Monatsnummer ( 01 .... 12 ) vorschlagen, ausser irgendjemand plädiert dringen für eine Option für "Monatsnamen"

Nur was ist "normiert"?
Ich kenne in Deutschland allein schon 3 verschiedene.

Und wie Du schon andeutest, was ist außerhalb von Deutschland?
Schließlich entpuppt sich Ahnenblatt immer mehr als internationales Programm

Gruß Hugo

Vielen Dank für die interessanten Beispiele. Einige Fehler haben sich ja dabei aufgetan ...

Marcus hat geschrieben:Ahnenblatt: Import aus einer Gedcom-Datei (problematische Fälle)

BEF DEC 1923 ---> 12.1923
AFT APR 1943 ---> 04.1943
BEF 31 DEC 1923 ---> 31.12.1923
AFT 1 JAN 2003 ---> 01.01.2003
"vor" und "nach" werden unterschlagen.

FROM JAN 1967 TO DEC 1968 ---> 01.1967 12.1968
FROM 1 JAN 1970 TO 31 DEC 1971 ---> 01.01.1970 31.12.1971
BET JUN 1927 AND DEC 1927 ---> 06.1927 12.1927
BET 1 JAN 2006 AND 30 JUN 2006 ---> 01.01.2006 30.06.2006
- Keine Unterscheidung zwischen "von bis" und "zwischen und". Werden beim Export wieder nur als Textfelder behandelt.

29 FEB 1900 ---> 30.12.1899
31 APR 1901 ---> 30.12.1899
- Nicht existierende Daten werden auf ein anderes Datum gesetzt: Ein Tag vorm frühesten Datum in der Datei?

Die obigen Beispiele in denen die Gedcom-Schlüsselwörter (BEF, AFT, FROM, ...) verloren gehen laufen in der nächsten Programmversion korrekt.
Ein Programmierfehler, bei dem nur eine Zeile geändert werden musste (genauer gesagt zwei Zeichen) ...

Die beiden nicht-existenten Daten am Ende werden in der kommenden Version ebenfalls "korrekt" behandelt. Hier die Ursache eine Systemfunktion, die von mir nicht in jedem Fall korrekt ausgewertet wurde (30.12.1899 ist anscheinend das kleinste mögliche Windows-Datum).

Gruß, Dirk.

Hugo hat geschrieben:

Marcus hat geschrieben:Ahnenblatt: Noch nicht umgesetzte Gedcom-Tags beim Export?
verstorben ---> verstorben
Früh gestorben ---> Früh gestorben
Tot geboren ---> Tot geboren
Totgeburt ---> Totgeburt

Nach Gedcom müßte es heißen:
verstorben ---> DECEASED
Früh gestorben ---> DEAD
Tot geboren ---> STILLBORN
Totgeburt ---> STILLBORN

Für die genannten Varianten gibt es definitiv keine Gedcom-Tags (laut Gedcom 5.5 Doku).
Allerdings werden DECEASED, DEAD und STILLBORN von (älteren?) PAF-Versionen verwendet. Nun stammt zwar PAF genauso wie der GEDCOM-Standard von den Mormonen, allerdings sind hier (müsste heißen "waren hier" - beide Entwicklungen sind "uralt") unterschiedliche Teams am Werke, die sich anscheinend nicht in allen Belangen absprechen ...

Ahnenblatt trägt diesem Umstand Rechnung indem beim Export der Originaltext exportiert wird und beim Import die Texte wie folgt umgesetzt werden ...

STILLBORN ---> tot geboren
DECEASED ---> verstorben
DEAD ---> tot

Es gibt noch viele weitere solche PAF-Besonderheiten, von denen ich nur beispielhaft folgende erwähnen will ...

NOT MARRIED ---> nicht verheiratet

Kommt allerdings nur bei Hochzeitsdaten vor (sollte zumindest).

Allerdings erkennt Ahnenblatt diese PAF-Tags nur alleinstehend, nicht in Verbindung mit einem Datum ...

DECEASED ---> verstorben
DECEASED 20 FEB 1980 ---> 02.1980
(letzteres überrascht mich jetzt auch ein wenig - daran sollte man noch arbeiten ... )

Abgesehen, dass der "Mehrwert" dieser DECEASED-Angabe zusammen mit einem Datum zweifelhaft ist ... gibt es ein Programm, dass solche GEDCOM-Konstrukte überhaupt erzeugt ...?

Und was sagt der Gedcom-Standard dazu (v.5.5) ...?

GEDCOM 5.5 hat geschrieben:Codes in Event Date:
Some applications, such as Personal Ancestral File, pass key words as part of certain event dates. Some of these key words were INFANT, CHILD, STILLBORN, etc. These have to do with being an approximate age at an event.

In this version of GEDCOM, the information has been removed from the date value and specified by an <AGE_AT_EVENT> key word value which indicates a descriptive age value at the time of the enclosing event. (See <AGE_AT_EVENT>, page 41.) For example:
1 DEAT
2 DATE 13 MAY 1984
2 AGE STILLBORN
meaning this person died at age approximately 0 days old.
1 DEAT
2 DATE 13 MAY 1984
2 AGE INFANT
meaning this person died at age less than 1 year old.

Gruß, Dirk.

Marcus hat geschrieben:Ich würde sogar soweit gehen und behaupten dass es alle als Datum erkannten Werte richtig exportiert. Wenn etwas nicht korrekt exportiert wird, liegt das derzeit höchstens noch daran, dass man etwas als Datum eizugeben meint, dass Ahnenblatt nicht als Fragment eines solchen erkennt. Der 01.??.2006 wäre so ein Beispielt (so weit ich mich erinnere). Wenn man sich hier beim Monat nicht mehr sicher war, nützt es auch nix den Tag zu wissen - dies wird als Text exportiert.

Der Grund ist, dass der Gedcom-Standard ein Datum ohne Tag erlaubt (z.B. "FEB 1980"), ohne Monat allerdings nicht (z.B. "01 2006" ist kein erlaubtes Gedcom-Datum).
Daher der Textexport ...

Gruß, Dirk.

Guten Tag Dirk

DirkB hat geschrieben:DECEASED 20 FEB 1980 ---> 02.1980
(letzteres überrascht mich jetzt auch ein wenig - daran sollte man noch arbeiten ... )

Vielleicht liegt das Problem daran (siehe Tabelle, die ich Dir geschickt habe)
das Ahnenblatt beim Import nur Datumszusätze Jahr erlaubt. Sobald das Datum vollständiger wird, gehen die Datumszusätze flöten.
Gruß Hugo

PS: Die Datumszusätze hatte ich aus Gedcom 5.5.1 rausgesucht.