GEDCOM/DATE-Tag

Name und Bedeutung

Tag

DATE

Formelle Bezeichnung

DATE

Deutsche Bezeichnung

Datum

Verwendung

Mit dem tag DATE wird der Zeitpunkt oder die Dauer eines Ereignisses, einer Eigenschaft oder einer Handlung beschrieben.

Formale Beschreibung zulässiger Werte

Basis

Basis dieser Beschreibung: GEDCOM Standard Draft 5.5.1

Der Standard erlaubt die Verwendung verschiedener Kalender, wie gregorianischer, julianischer oder französischer Kalender. Diese Kalender sind auch in der Gedcom-L behandelt worden.

Standardfall

Die wohl am meisten genutzte Angabe ist die eines exakten Tages:

n DATE <TAG> <MONAT> <JAHR>

Beispiel:

n DATE 15 SEP 2001

Es gelten folgende Regeln:

<TAG> := dd ein- oder zweistellige Zahl, die den Tag im Monat angibt

! Achtung: nur für den Monat gültige Tage sind zulässig.

<MONAT> := JAN | FEB | MAR | APR | MAY | JUN | JUL | AUG | SEP | OCT | NOV | DEC

! Achtung: der Monat wird gebildet aus den ersten drei Buchstaben des englischen Monatsnamens, alle Buchstaben groß. Andere Bezeichnungen sind nicht zulässig.

<JAHR> := jjjj

bis zu vierstellige Zahl, die das Jahr angibt.

Unvollständige Datumsangaben

Gegenüber dem Standardfall können die Angabe des Tages oder die Angaben des Tages und des Monats weggelassen werden:

n DATE <MONAT> <JAHR>

oder

n DATE <JAHR>

Beispiele:

n DATE SEP 2001

oder

n DATE 2001

Mit solchen Angaben werden unvollständig bekannte Zeitpunkte ( z.B. Tag nicht bekannt ) bezeichnet. n DATE 2001 sagt also: Der Zeitpunkt war zwischen dem 1.Januar 2001 und dem 31.Dezember 2001.

Zeit-Bereiche

Wenn ein exakter Zeitpunkt nicht bekannt ist, kann auch ein Zeitbereich angegeben werden. Die Bedeutung ist, dass der genaue, aber nicht bekannte Zeitpunkt des Ereignisses innerhalb des definierten Zeit-Bereiches liegt:

n DATE BET <Datum1> AND <Datum2>

oder

n DATE BEF <Datum>

oder

n DATE AFT <Datum>

Beispiele:

n DATE BET 1659 AND 1687

bedeutet: das Ereignis hat zwischen dem 1.Januar 1659 und dem 31.12.1687 stattgefunden. Der Standard sieht explizit vor, dass die "Grenzjahre" (hier: 1659 und 1687) zu dem Zeit-Bereich dazugehören.

n DATE BET 15 FEB 2001 AND 23 MAR 2001

bedeutet: Das Ereignis hat zwischen dem 15. Februar 2001 und dem 23. März 2001 stattgefunden.

n DATE BEF 12 OCT 1999

bedeutet: Das Ereignis hat vor dem 12. Oktober 1999 stattgefunden.

n DATE AFT 1700

bedeutet: Das Ereignis hat nach dem 31. Dezember 1700 stattgefunden.

Ungefähre Zeitangaben

Für ungefähre Zeitangaben sind folgende Möglichkeiten vorgesehen:

n DATE ABT <Datum>

oder

n DATE CAL <Datum>

oder

n DATE EST <Datum>

Beispiele:

n DATE ABT 1700

bedeutet: Das Ereignis trat um 1700 herum ein. Hiermit wird keine Aussage gemacht, wie weit von 1700 entfernt das Ereignis stattfand.

n DATE CAL JUN 1910

bedeutet: Aus anderen bekannten Fakten wurde errechnet, dass das Ereignis im Juni 1910 eintrat.

n DATE EST 1875

bedeutet: Die Zeitangabe wurde geschätzt.

Zeit-Dauer

Dauert eine Eigenschaft über eine bestimmte Zeitdauer an (z.B. Ausübung eines Berufes, wohnen an einem bestimmten Ort), so wird das so dargestellt:

n DATE FROM <Datum1> TO <Datum2>

oder

n DATE FROM <Datum>

oder

n DATE TO <DATUM>

Beispiele:

n DATE FROM 12 SEP 2001 TO 19 SEP 2001

bedeutet: Der Vorgang dauerte vom 12. bis zum 19. September 2001.

n DATE FROM 1700

bedeutet: Der Vorgang begann im Jahr 1700, über sein Ende wird keine Aussage gemacht.

n DATE TO 1875

bedeutet: Der Vorgang dauerte bis zum Jahr 1875, über seinen Anfang wird keine Aussage gemacht.

Klartext-Angaben

Der GEDCOM Standard 5.5.1 läßt unter dem tag DATE auch Klartext-Angaben zu:

n DATE (...Text...)

Beispiel:

n DATE (Pfingstsonntag 1898)

bedeutet: Das Ereignis fand am Pfingstsonntag statt.

! Achtung:

Klartextangaben müssen immer in einfache Klammern gesetzt werden.

Klartextangaben dürfen nicht in Zeit-Bereichen oder Zeit-Dauern verwendet werden, auch ungefähre Zeitangaben mit Klartext sind im Standard nicht zugelassen. Die Kombination von z.B. ABT, FROM, BET usw. mit Klartextangaben ist also nicht zulässig.

Der Standard bietet eine Möglichkeit, den Klartext mit einer einfachen Datumsangabe zu kombinieren:

n DATE INT <Datum> (...Text...)

Beispiel:

n DATE INT 31 MAY 2009 (Pfingsten 2009)

bedeutet: Das Ereignis fand Pfingsten 2009 statt, daraus wurde hergeleitet ( INT = interpretiert ), dass es der 31. Mai 2009 war.

! Achtung: Der Standard gibt empfohlene Mindestlängen für Felder vor, in diesem Fall einschliesslich von INT sollen mindestens 35 Zeichen unterstützt werden. Längere Texte werden evtl. von Programmen, die nur diese Mindestempfehlung umsetzen, nicht verstanden bzw. abgeschnitten.

Vereinbarungen für den tag DATE

Vorbemerkung

Der GEDCOM Standard Draft 5.5.1 ist Basis dieser Vereinbarungen.

Es ist Ziel der Arbeitsgruppe von Compgen und den Programmautoren, den Datenaustausch zwischen Programmen sicherer und verlustfreier zu gestalten. Es ist daher nicht Ziel, programm-interne Formate für Datumsangaben zu vereinbaren. Insbesondere bleibt es die freie Entscheidung eines jeden Programmautors, wie er auf der Benutzeroberfläche seines Programmes die Datumsangaben und/oder Kalenderinformationen anzeigt oder eingeben läßt. Die Verantwortung des Programmautors ist es dann aber, beim Export von Datumsangaben in eine GEDCOM-Datei die Anforderungen des Standards bezüglich der zulässigen Formen der Datumsangabe in der GEDCOM-Datei zu erfüllen. Die Diskussion in der Arbeitsgruppe (über die Gedcom-L geführt) hat im wesentlichen zu einer Bekräftigung der Standardvorgaben geführt.

Die nachfolgenden Punkte sind bereits per Abstimmung unter den Programmautoren vereinbart worden.

Vereinbarungen zum Export des tag DATE

Die im Punkt E7(2) zusammengefassten Themen wurden wegen der noch anhaltenden Diskussion in der Liste hier herausgenommen und werden - ggfs modifiziert oder ergänzt - später zur Abstimmung gestellt.

E1 Grundelemente der Datumsangabe

Beim Export müssen alle Grundelemente der Datumsangabe unterstützt werden:

• a) das Format des exakten Datums
  • n DATE <TAG> <MONAT> <JAHR>

mit:

• <TAG> := dd ein- oder zweistellige Zahl, die den Tag im Monat angibt. Nur für den Monat gültige Tage sind zulässig.

• <MONAT> := JAN | FEB | MAR | APR | MAY | JUN | JUL | AUG | SEP | OCT | NOV | DEC

Andere Schreibweisen oder Bezeichnungen für Monate sind nicht zulässig. Ausnahmen bei französischem und hebräischen Kalender siehe E5.

• <JAHR> := jjjj oder <JAHR> := jjjj/jj

bis zu vierstellige Zahl, die das Jahr angibt. Ggfs ergänzt um einen Schrägstrich und zwei weitere Ziffern. Mit dieser Ergänzung darf nur die Unsicherheit beim englischen Kalender bezüglich des Jahresbeginns vor 1752 gekennzeichnet werden.

• b) die Formate unvollständiger Datumsangaben
  • n DATE <MONAT> <JAHR>
  • n DATE <JAHR>
  • n DATE <JAHR>B.C.

• c) die Formate für Zeit-Bereiche
  • n DATE BET <Datum1> AND <Datum2>
  • n DATE BEF <Datum>
  • n DATE AFT <Datum>

Andere Bezeichnungen oder Schreibweisen als BET, AND, BEF und AFT dürfen nicht verwendet werden.

• d) die Formate ungefährer Zeitangaben
  • n DATE ABT <Datum>
  • n DATE CAL <Datum>
  • n DATE EST <Datum>

Andere Bezeichnungen oder Schreibweisen als ABT, CAL und EST dürfen nicht verwendet werden.

• e) die Formate der Zeit-Dauer
  • n DATE FROM <Datum1> TO <Datum2>
  • n DATE FROM <Datum>
  • n DATE TO <Datum>

Andere Bezeichnungen oder Schreibweisen als FROM und TO dürfen nicht verwendet werden.

Die Angaben zu Zeitbereichen, ungefähren Zeitangaben und Zeit-Dauer dürfen nicht in einem Datum miteinander kombiniert werden.

E2 Klartext-Angaben im Datum

Wenn das Programm Klartextangaben für Datum intern unterstützt, muss Klartext beim Export in folgenden Formaten exportiert werden:

• n DATE (Klartext)
• n DATE INT <einfach_datum> (Klartext)

Für das <einfach_datum> darf hierbei nur ein Einfachdatum, d.h. die Formate E1a) und E1b), eingesetzt werden.

E3 Interpretation von Klartexten

Eine Interpretation von Datums-Klartext muss so weit wie möglich vor dem Export erfolgen. Das Ergebnis muss in der Form

• n DATE INT <einfach_datum> (Klartext)

oder ohne Klartext nach E1 exportiert werden, wenn ein Interpretationsergebnis erreicht wurde. Die Form

• n DATE (Klartext)

darf nur verwendet werden, wenn aus dem Klartext ein <einfach_datum> oder Datum nach E1 nicht ableitbar ist.

E4 Klammern um Klartexte

Klartextangaben aus E2 bzw E3 müssen immer in einfache Klammern gesetzt werden.

E5 Verschiedene Kalenderarten

Der Export von Datumsangaben mit den im Standard 5.5.1 explizit genannten Kalenderarten darf unterstützt werden:

• <Datum> := @#DGREGORIAN@ <DATE_GREG>
• <Datum> := @#DJULIAN@ <DATE_JULN>
• <Datum> := @#DHEBREW@ <DATE_HEBR>
• <Datum> := @#DFRENCH R@ <DATE_FREN>

Für <DATE_GREG> und <DATE_JULN> gilt die Vereinbarung E1a und E1b. Bei <DATE_JULN> darf die Jahresangabe aus E1a) mit Schrägstrich nicht eingesetzt werden. Für <DATE_FREN> und <DATE_HEBR> gelten E1a) und E1b) mit abweichenden Monatsbezeichnungen. Es müssen die im Gedcom Standard 5.5.1 genannten Monatsbezeichnungen verwendet werden.

Die oben definierten Kalender-Daten <Datum> werden entweder als

• n DATE <Datum>

oder nach Einsetzen in die Formate E1c, E1d oder E1e exportiert.

E6 Ausschluss weiterer Formate

Andere Datums-Formate als die in E1 bis E5 beschriebenen Formate dürfen nicht exportiert werden.

E8 Angabe der expliziten Kalenderarten

Der Export von Datumsangaben muss die explizite Kalenderart enthalten, wenn der Anwender diese Kalenderart selbst eingegeben hat. In allen anderen Fällen darf das Datum ohne expliziten Kalendertyp exportiert werden.

E9 Datumsangaben in verschiedenen Strukturen

Datumsangaben im Rahmen folgender Strukturen nach GEDCOM Standard 5.5.1:

• EVENT_DETAIL
• ENTRY_RECORDING_DATE
• DATE_LDS_ORD

dürfen den vollen Umfang nach E1 nutzen.

Datumsangaben im Rahmen:

• CHANGE_DATE
• PUBLICATION_DATE
• TRANSMISSION_DATE

müssen laut Standard als DATE_EXACT, d.h. in der in E1a) beschriebenen Form exportiert werden.

Vereinbarungen zum Import des tag DATE

I1 Unterstützung der Standard-Formate

Die Datums-Formate nach E1 bis E5 müssen beim Import unterstützt werden, soweit das importierende Programm die jeweilige Datumsdarstellung intern verarbeiten kann ( ggfs Einschränkungen bei Klartext, Kalendertypen ).

I2 Unterstützung anderer Datums-Formate

Andere Datumsformate als in E1 bis E5 definiert dürfen im Import unterstützt werden.

I3 Behandlung von Datums-Klartext

Ein mit Klammern als Klartext gekennzeichneter Datumsanteil darf vom importierenden Programm beim Import nicht verändert werden. Die den Klartext kennzeichnenden Klammern gehören nicht zu diesem Datumsanteil. Es muss sichergestellt werden, dass bei einem späteren Export des Klartextes keine Doppelung der Klammern erzeugt wird.

I4 Datumsangaben ohne expliziten Kalendertyp

Einem Datum ohne zugewiesenem Kalendertyp darf beim Import nicht automatisch ein Kalendertyp zugewiesen werden.

I5 Verbot der Interpretation von eingeklammertem Klartexten beim Import

Eine Interpretation von eingeklammertem Klartext darf beim Import nicht erfolgen (Interpretation erfolgte bereits gemäss E3 und E4 vor dem Export).

I6 Import von Klartext ohne Klammern Nicht eingeklammerte Klartexte dürfen interpretiert werden. Nach den Exportvereinbarungen betrifft das nur den Import von Dateien, die nicht diesen Vereinbarungen der Programmautoren unterliegen oder von älteren Programmversionen erzeugt wurden.

Sonstige Vereinbarungen zum tag DATE

Der Punkt S3(2) wurde wegen der noch anhaltenden Diskussion in der Liste hier herausgenommen und wird - ggfs modifiziert oder ergänzt - später zur Abstimmung gestellt.

S1 Mindest-Feldlängen

Die im Gedcom-Standard angegebenen Mindest-Feldlängen müssen unterstützt werden.

S2 Feldlängen bei Klartext

Für Datums-Klartext wird beim Export in der Form E2 bzw E3 die Unterstützung von mehr Zeichen als der im Standard angegebenen Feldlänge von 35 Zeichen empfohlen, trotz des Risikos des Datenverlustes im empfangenden Programm (insbesondere bei Drittprogrammen). Beim Import wird die Unterstützung von mehr als 35 Zeichen empfohlen, damit auch längere Klartexte ohne Datenverlust zwischen den unter diesen Vereinbarungen arbeitenden Programmen ausgetauscht werden können.

Diskussion Runde 2: Weitere Themen

fiktives Datum zum Sortieren

Problem: Für verschiedene Zwecke, wie z.B. für das Sortieren, für das Suchen von Dubletten oder für Datenschutzmodule sind auch dann Datumsangaben wünschenswert, wenn der Anwender kein Datum - insbesondere zur Geburt und zur Heirat - eingegeben hat. Meist liegt das daran, dass die ausgewertete Quelle kein Datum enthielt bzw für das Ereignis keine Quelle vorliegt. In solchen Fällen kann dann ein ungefähres Datum ermittelt werden (z.B. aus den Lebensdaten der Person(en), der Eltern, Ehegatten, Kinder...) und als fiktives Datum für die programminternen Aufgaben wie Sortieren eingesetzt werden. Die so ermittelten fiktiven Datumsangaben sollen aber in der Regel nicht in Berichte einfließen, was aber beim Austausch per GEDCOM in der normalen Datenstruktur leicht passieren kann. Wenn der Anwender dagegen selber die Daten auch in Berichten sehen will, dann stehen die Möglichkeiten des Standard mit DATE ABT, EST, BET ... AND usw zur Verfügung.

Lösungsansatz:

Es wird ein fiktives Datum eingeführt, welches ausschließlich für die genannten Zwecke, jedoch nicht für Berichte, Ahnentafeln, Stammbäume etc vorgesehen ist. Der Einbau in Datensätze ( INDI, FAM ) soll so erfolgen, dass bei Programmen, die die Konstruktion nicht kennen, bevorzugt ein Weglassen der Daten erfolgt. Daher hat die Liste folgenden Vorschlag diskutiert:

• 1 _SORT
• 2 TYPE fikt.
• 2 DATE <datum>

Detaildiskussionen behandelten die Frage, ob TYPE erforderlich ist: Über TYPE BIRT könnte explizit auch ein Geburtsdatum, über TYPE DEAT dagegen ein Sterbedatum herangezogen werden.

Der Lösungsansatz könnte erweitert werden, indem auch PLAC unter 1 _SORT gestellt wird, um Sortierungen nach Orten auch zu ermöglichen.

Ein weiterer Vorschlag sieht vor, in der <<EVENT_DEATIL>> ein Kennzeichen _SORT unterzubringen, damit sähe diese Variante so aus:

• 1 BIRT
• 2 _SORT <datum>

Die Alternativlösung, in der normalen Struktur z.B.

• 1 BIRT
• 2 DATE SORT <datum>

zu verwenden, wurde zurückgestellt: Sie widerspricht explizit dem GEDCOM-Standard, und sie läuft in die Gefahr, dass Programme ohne Überwachung der Datumsformate das "SORT <datum>" 1:1 in die Berichte einstellen.

Die Diskussion hierzu ist noch nicht angeschlossen.

Behandlung/Darstellung schwieriger Situationen

Folgende Themen sind derzeit in der GEDCOM-Arbeitsgruppe von Compgen mit den Programmentwicklern diskutiert worden. Das Diskussionsergebnis ist in den Entscheidungsvorschlag eingeflossen:

In bisherigen Abstimmungen nicht aufgerufene Punkte

Folgende Entscheidungsvorschläge wurden in den bisherigen Abstimmrunden zurückgestellt, da die Diskussion in der Gedcom-L zu diesen Punkten noch sehr intensiv weitergeführt wurde. Die Kennung (2) deutet an, dass es sich um eine Formulierung aus der Diskussion vor der 2. Abstimmrunde handelt.

E7(2) Weitere Exportoptionen

Über weitere Exportoptionen mit Textanteilen für Datumsinformationen wird nicht entschieden, bevor die Themen NOTE und SOUR behandelt sind. Ergibt sich dann aus der Diskussion ein zusätzlicher Entscheidungs-Bedarf über E1 bis E6 hinaus, wird das Thema DATE mit diesem Umfang für eine weitere Abstimmung vorbereitet. Auch das neu in der Liste hochgekommene Thema, ob solche Konstrukte wie von PAF erzeugt:

• n DATE NOT MARRIED

wieder ohne Klammern exportiert werden dürften (da PAF es mit Klammern nicht mehr versteht), konnte in dem jetzigen Entscheidungsvorschlägen noch nicht verarbeitet werden und wird bei Bedarf zu einem späteren Zeitpunkt noch einmal aufgerufen.

S3(2) Export längerer Klartexte

Bei Bedarf wird über den Export längerer Klartexte (größer 35 Zeichen) zusammen mit E7 später erneut diskutiert und entschieden.

Abweichungen vom Standard beim GEDCOM-Export

Mehrere Programme exportieren andere Formate für das Datum als im Standard definiert bzw. verwenden Klartextangaben ohne die vorgeschriebenen Klammern. Solche Abweichungen können beim Einlesen in andere Programme zu Fehlinterpretationen oder Datenverlusten führen. Einige Programmentwickler haben bereits angekündigt, mit den nächsten Programmversionen diese Abweichungen vom Standard zu beheben.

Status:

Entscheidungsvorschlag formuliert, teilweise bereits Vereinbarung getroffen

Einige Programme kombinieren eine Zeitdauer mit ungefähren Zeitangaben wie z.B.:

n DATE FROM ABT <datum> TO AFT <datum>

Dies ist nach GEDCOM Standard nicht zulässig, da im DATE_VALUE nur alternativ eine Periode, ein Zeitbereich oder ein ungefähres Datum verwendet werden kann. Kombinationen dieser Elemente sind nicht vorgesehen.

Status:

Vereinbarung getroffen

Standard-Format versus Klartext-Format

Es gibt Programme, die beim Export nur die zulässigen Formate ohne Klartext exportieren. Andere Programme exportieren grundsätzlich nur Klartextangaben. Beim Einlesen der GEDCOM in die jeweils andere Programmgruppe ist der Verlust der Information zu erwarten.

Status:

Entscheidungsvorschlag formuliert

Klartext Format

Die im Standard vorgesehene Darstellung des Klartextformates ( mit Klammern, bzw mit INT ) kann von vielen Programmen nicht interpretiert werden.

Status:

Entscheidungsvorschlag formuliert

Verwendung verschiedener Kalender

Das Thema der Verwendung verschiedener Kalender ( Gregorianischer, Julianischer, französicher, hebräischer ) ist diskutiert. Hauptsächliche Diskussionspunkte waren:

• Interpretation bei nicht angegebenem Kalendertyp
• Mögliche Umrechnung in den Gregorianischen Kalender

Status:

Vereinbarung getroffen