GEDCOM/DATE-Tag

From GenWiki

Jump to: navigation, search

This page is an English extract of the German page GEDCOM/DATE-Tag [1], for full details see the German page.

Contents

Name and Meaning

Tag

DATE

Meaning

DATE

Usage

By the tag DATE the exact date or the duration of an event, an attribute of an action is described.

Formal Description of Permissible Values

Base: GEDCOM Standard Draft 5.5.1

The standard allows the use of different calendars such as Gregorian, Julian or French calendar. These calendars have been discussed in the Gedcom-L.

Standard Case

The most likely used case is the definition of an exact date:

n DATE <DAY> <MONTH> <YEAR> ( as Gregorian year)

Example:

n DATE 15 SEP 2001

The following rules apply:

<DAY> := dd

One- or two-digit number indicating the day of the month

Note: Only valid days for the month are allowed.

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

Note: The month is formed from the capitalized first three letters of the English month name. Other notations are not allowed.

<YEAR> := yyyy

Up to a four-digit number indicating the year

Incomplete Dates

Compared to the standard case, the data for the day or the day and the month may be omitted:

n DATE <MONTH> <YEAR>

or

n DATE <YEAR>

Examples:

n DATE SEP 2001

or

n DATE 2001

With such statements incompletly known points in time ( e.g. day not known ) may be defined and "n DATE 2001" means the date was between 1 January 2001 and 31 December 2001.

Date Ranges

If an exact date is not known, a date range can be specified. The date range is an estimate that an event happened on a single date somewhere in the date range specified.

n DATE BET <Date1> AND <Date2>

or

n DATE BEF <Date>

or

n DATE AFT <Date>

Examples:

n DATE BET 1659 AND 1687

means: The event happened between 1 January 1659 and 31 December 1687. The standard explicitly defines that the "marginal years " ( in this case 1659 and 1687 ) belong to the date range.

n DATE BET 15 FEB 2001 AND 23 MAR 2001

means: The event happened between 15 February 2001 and 23 March 2001.

n DATE BEF 12 OCT 1999

means: The event happened before 12 October 1999.

n DATE AFT 1700

means: The event happened after 31 December 1700.

Approximated Dates

For approximate dates following options are provided:

n DATE ABT <Date>

or

n DATE CAL <Date>

or

n DATE EST <Date>

Examples:

n DATE ABT 1700

means: The date is not exact, but about 1700. By this no statement is made as far away from 1700 the event took place.

n DATE CAL JUN 1910

means: Calculated mathematically, for example, from an event date and age. From other known facts, it was calculated that the event occurred in June 1910.

n DATE EST 1875

means: Estimated based on an algorithm using some other event date.

Date Periode

Takes a property over a certain period of time ( e.g. exercise of a profession, living in a particular place ), it is shown as:

n DATE FROM <Date1> TO <Date2>

or

n DATE FROM <Date>

or

n DATE TO <Date>

Examples:

n DATE FROM 12 SEP 2001 TO 19 SEP 2001

means: The state of some attribute existed from 12 Septemner 2001 to 19 September 2001.

n DATE FROM 1700

means: The state of the attribute began in 1700 but the end date is unknown.

n DATE TO 1875

means: The state ended in 1875 but the begin date is unknown

Date Phrases

The GEDCOM Standard 5.5.1 allows date phrases as text:

n DATE (...Text...)

Example:

n DATE (Whit Sunday 1898)

means: The event took place at Whit Sunday 1898.

Note: Date phrases always must be enclosed in single brackets.

Date phrases may not be used in date ranges or date periods. Also approximated dates and date phrases are not allowed according to the standard. Therefor combination of e.g. ABT, FROM, BET, etc. with date phrases are not permitted.

The standard provides a way to combine the date phrases with a simple date according:

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

Example:

n DATE INT 31 MAY 2009 (Pentecost 2009)

means: The event happened at Pentecost 2009, it was derived ( INT = interpreted ) that it was May 31, 2009

! Note: The standard provides minimum recommended lengths for fields, in this case, at least 35 characters including INT should be supported. Longer texts may not be understood by other programs that implement only the minimum recommendation and therefor cutted off.

As additional information the standard defines: As a general rule, events are things that happen on a specific date. Use the date form ‘BET date AND date’ to indicate that an event took place at some time between two dates. Resist the temptation to use a ‘FROM date TO date’ form in an event structure. If the subject of your recording occurred over a period of time, then it is probably not an event, but rather an attribute or fact.

Agreements for DATE

The agreements for DATE are derived from the discussion on the Gedcom-L. They were decided by a vote of the program authors of the list.

Export of DATE

E1 Basic Elements of Dates

When exporting, all basic elements of DATE must be supported:

a) The format of the exact dates

  • n DATE <DAY> <MONTH> <YEAR>

with

<DAY> := dd

One- or two-digit number indicating the day of the month. Only valid days for the month are allowed.

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

Other notations are not allowed, except French and Hebrew calendar see E5.

<YEAR> := yyyy or <YEAR> := yyyy/yy

Up to a four-digit number indicating the year, possibly supplemented by a slash and two more digits. With this addition, only the uncertainty of the English calendar regarding start of the year before 1752 may be marked.

b) The format for incomplete dates

  • n DATE <MONTH> <YEAR>
  • n DATE <YEAR>
  • n DATE <YEAR>B.C.

c) The format for date ranges

  • n DATE BET <Date1> AND <Date2>
  • n DATE BEF <Date>
  • n DATE AFT <Date>

Other notations than BET, AND, BEF and AFT are not allowed.

d) The format for approximated date

  • n DATE ABT <Date>
  • n DATE CAL <Date>
  • n DATE EST <Date>

Other notations than ABT, CAL und EST are not allowed.

e) The format for date periods

  • n DATE FROM <Date1> TO <Date2>
  • n DATE FROM <Date>
  • n DATE TO <Date>

Other notations than FROM und TO are not allowed.

The information on time ranges, approximate dates, and time periods may not be combined with each other in a date.

E2 Text Phrases in Date

If the program supports internally text phrase information for Date, text phrases must be exported according the following formats:

n DATE (text phrase)

or

n DATE INT <simple_date> (text phrase)

For <simple_date> only the formats according die Formate E1a and E1b may be used.

E3 Interpretation of Text Phrases

An interpretation of text phrases must be made as much as possible prior to the export. The result must be exported in the form

n DATE INT <simple_date> (text phrase)

or without plain text according to E1 when an interpretation result was achieved. The form

n DATE (text phrase)

may only be used, when from the text phrase no <simple_date> or date according E1 is not derivable.

E4 Brackets around Text Phrases

Date phrases according E2 and E3 always must be enclosed in single brackets.

E5 Various Types of Calendars

The export of dates with the calendar types explicitly mentioned in Standard 5.5.1 should be supported:

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

For <DATE_GREG> and <DATE_JULN> the agreement E1a and E1b applies. For <DATE_JULN> the year value according E1a with a slash should not be used. For <DATE_FREN> and <DATE_HEBR> E1a and E1b apply with different months names. The months names defined in Gedcom Standard 5.5.1 must be used.

The above defined calendar data <Date> have to be exported either by n DATE <Date> or after insertion according the formats E1c, E1d or E1e.

E6 Exclusion of other Formats

Other date formats as the formats described in E1 to E5 should not be exported.

E8 Statement of the explicit Type of Calendars

The export of dates shall include the explicit calendar type, if the user has entered this calendar type himself. In all other cases the date without explicit calendar type can be exported.

E9 Dates in Different Structures

Dates within the following structures according GEDCOM Standard 5.5.1 may use the full scope of E1:

  • EVENT_DETAIL
  • ENTRY_RECORDING_DATE
  • DATE_LDS_ORD

The following dates

  • CHANGE_DATE
  • PUBLICATION_DATE
  • TRANSMISSION_DATE

must be exported, according Standard 5.5.1, as DATE_EXACT, i.e. according the form described in E1a.

Import of DATE

I1 Support of Standard Formats

The date formats according to E1 to E5 must be supported during import, as long as the importing program can process the appropriate date representation internally ( if applicable restrictions in text phrases and/or calendar types ).

I2 Support of Other Date Formats

Other date formats as defined in E1 to E5 may be supported during import.

I3 Handling of Text Phrases

A text phrase, marked by surrounding brackets, must not be changed by the importing program during import. The characterizing brackets do not belong to this date part. It must be ensured that at a later export of the text phrase no duplication of the brackets is generated.

I4 Dates without Explicit Calendar Type

For a date without an assinged calendar type, its not allowed to assign automatically a calendar type during importing.

I5 Prohibition of Interpretation of Bracketed text phrases during Import

An interpretation of bracketed text phrases during import is not allowed ( Interpretation already done according to E3 and E4 before export ).

I6 Import of Text Phrases without Brackets

No bracketed text phrases may be interpreted.

Other Agreements to DATE

S1 Minimum Field Lengths

The minimum field lengths defined by the Gedcom standard must be supported.

S2 Field Lengths for Text Phrases

For exporting text phrases according the form E2 or E3 it is recommended to support more than 35 characters for field length specified in the standard, despite the risk of data loss in the receiving program. For importing the support of more than 35 characters is recommended, to transfer longer text phrases without data loss between programs working according these agreements.

Personal tools
GenWiki-internal
In other languages