GEDCOM/DATE-Tag - Versionsgeschichte

Dhesmer: Engl Link entfernt

2023-09-19T15:39:27Z

Engl Link entfernt

← Nächstältere Version		Version vom 19. September 2023, 17:39 Uhr
Zeile 465:		Zeile 465:


	~~<!-- Sortierfolge auf der Kategorienseite gemäß letzten Teil des Titelpfades -> also dem Tagnamen -->~~
	[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]
	[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]<!-- Sortierfolge auf der Kategorienseite gemäß letzten Teil des Titelpfades -> also dem Tagnamen -->

	~~[[en:{{PAGENAME}}]]~~

AEmmerich: /* Verwendung verschiedener Kalender */ Direktzuordnung zu GEDCOM entfernt

2019-02-07T12:56:40Z

Verwendung verschiedener Kalender: Direktzuordnung zu GEDCOM entfernt

← Nächstältere Version		Version vom 7. Februar 2019, 14:56 Uhr
Zeile 468:		Zeile 468:
	[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]
	[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]
	~~[[Kategorie:GEDCOM\|Date-Tag]]~~

	[[en:{{PAGENAME}}]]		[[en:{{PAGENAME}}]]

Bohrmann: Kat eingefügt

2018-03-22T11:54:00Z

Kat eingefügt

← Nächstältere Version		Version vom 22. März 2018, 13:54 Uhr
Zeile 468:		Zeile 468:
	[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]
	[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]
			[[Kategorie:GEDCOM\|Date-Tag]]

	[[en:{{PAGENAME}}]]		[[en:{{PAGENAME}}]]

AEmmerich: /* fiktives Datum zum Sortieren */

2013-07-20T08:48:09Z

fiktives Datum zum Sortieren

← Nächstältere Version		Version vom 20. Juli 2013, 10:48 Uhr
Zeile 383:		Zeile 383:
	* 1 BIRT		* 1 BIRT
	* 2 _SORTDATE <datum>		* 2 _SORTDATE <datum>
	um besser kenntlich zu machen, dass es sich um ~~DAtum~~ handelt.		um besser kenntlich zu machen, dass es sich um Datum handelt.

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

AEmmerich: /* fiktives Datum zum Sortieren */ _SORTDATE ergänzt

2013-07-20T08:47:43Z

fiktives Datum zum Sortieren: _SORTDATE ergänzt

← Nächstältere Version		Version vom 20. Juli 2013, 10:47 Uhr
Zeile 380:		Zeile 380:
	* 1 BIRT		* 1 BIRT
	* 2 _SORT <datum>		* 2 _SORT <datum>
			oder auch:
			* 1 BIRT
			* 2 _SORTDATE <datum>
			um besser kenntlich zu machen, dass es sich um DAtum handelt.

	Die Alternativlösung, in der normalen Struktur z.B.		Die Alternativlösung, in der normalen Struktur z.B.
Zeile 386:		Zeile 390:
	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.		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~~.		Die Diskussion hierzu ist noch nicht abgeschlossen.

	== Behandlung/Darstellung schwieriger Situationen ==		== Behandlung/Darstellung schwieriger Situationen ==

AEmmerich: /* fiktives Datum zum Sortieren */ Vorschlag mit _SORT im EVENT_DETAIL ergänzt.

2013-07-20T08:44:20Z

fiktives Datum zum Sortieren: Vorschlag mit _SORT im EVENT_DETAIL ergänzt.

← Nächstältere Version		Version vom 20. Juli 2013, 10:44 Uhr
Zeile 376:		Zeile 376:

	Der Lösungsansatz könnte erweitert werden, indem auch PLAC unter 1 _SORT gestellt wird, um Sortierungen nach Orten auch zu ermöglichen.		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.		Die Alternativlösung, in der normalen Struktur z.B.
Zeile 381:		Zeile 385:
	* 2 DATE SORT <datum>		* 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.		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 ==		== Behandlung/Darstellung schwieriger Situationen ==

AEmmerich: /* Diskussion Runde 2: Weitere Themen */ fiktives Datum

2013-07-15T16:21:10Z

Diskussion Runde 2: Weitere Themen: fiktives Datum

← Nächstältere Version		Version vom 15. Juli 2013, 18:21 Uhr
Zeile 360:		Zeile 360:

	== Diskussion Runde 2: Weitere Themen ==		== 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.

			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.

	== Behandlung/Darstellung schwieriger Situationen ==		== Behandlung/Darstellung schwieriger Situationen ==

AEmmerich: /* Vereinbarungen für den tag DATE */ neuer Abschnitt für Runde 2

2013-07-15T15:58:12Z

Vereinbarungen für den tag DATE: neuer Abschnitt für Runde 2

← Nächstältere Version		Version vom 15. Juli 2013, 17:58 Uhr
Zeile 358:		Zeile 358:
	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).		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.		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 ==

	== Behandlung/Darstellung schwieriger Situationen ==		== Behandlung/Darstellung schwieriger Situationen ==

Ojay am 6. März 2012 um 21:12 Uhr

2012-03-06T21:12:54Z

← Nächstältere Version		Version vom 6. März 2012, 23:12 Uhr
Zeile 421:		Zeile 421:


	=== Verwendung verschiedener ~~Kalendar~~ ===		=== Verwendung verschiedener Kalender ===

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

Baumbuwegen: lang

2010-11-13T20:32:36Z

lang

← Nächstältere Version		Version vom 13. November 2010, 22:32 Uhr
Zeile 435:		Zeile 435:
	[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]
	[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]

			[[en:{{PAGENAME}}]]