+ /** \addtogroup parsed_date */
+ /** @{ */
+ /** \brief Date type
+
+ This determines which one of the serial day numbers (Julian days) are
+ relevant in the struct date.
+ */
+enum _Date_type {
+ DATE_UNRECOGNIZED, /**< Neither date#sdn1 as date#sdn2 are significant */
+ DATE_EXACT, /**< Only date#sdn1 is significant */
+ DATE_BOUNDED /**< Both date#sdn1 and date#sdn2 are significant */
+};
+
+ /** \brief Date type */
+typedef enum _Date_type Date_type;
+
+ /** \brief Calendar type
+
+ This determines the calendary type (see calendar overview LINK TBD).
+ */
+enum _Calendar_type {
+ CAL_GREGORIAN, /**< The Gregorian calendar */
+ CAL_JULIAN, /**< The Julian calendar */
+ CAL_HEBREW, /**< The Hebrew (Jewish) calendar */
+ CAL_FRENCH_REV, /**< The calendar used after the French Revolution */
+ CAL_UNKNOWN /**< An unknown calendar type */
+};
+
+ /** \brief Calendar type */
+typedef enum _Calendar_type Calendar_type;
+
+ /** \brief Year type
+
+ This determines whether the year has one value (e.g. 1677) or two values
+ (e.g. 1677/78, the first value is in annunciation style, the second in
+ circumcision style).
+ */
+enum _Year_type {
+ YEAR_SINGLE, /**< There is only one value for the year */
+ YEAR_DOUBLE /**< The date#year_str contains two values. Note that the
+ date#year
+ will then contain the circumcision style year, i.e. the
+ highest one */
+};
+
+ /** \brief Year type */
+typedef enum _Year_type Year_type;
+
+ /** \brief Date value type
+
+ This determines which members in the struct date_value are relevant, as
+ given in the description below.
+ */
+enum _Date_value_type {
+ /* Simple date */
+ DV_NO_MODIFIER, /**< Just a simple date: date1 */
+ /* Range values */
+ DV_BEFORE, /**< A range (BEFORE date1) */
+ DV_AFTER, /**< A range (AFTER date1) */
+ DV_BETWEEN, /**< A range (BETWEEN date1 AND date2) */
+ /* Period values */
+ DV_FROM, /**< A period (FROM date1) */
+ DV_TO, /**< A period (TO date1) */
+ DV_FROM_TO, /**< A period (FROM date1 TO date2) */
+ /* Approx values */
+ DV_ABOUT, /**< An approximation (ABOUT date1) */
+ DV_CALCULATED, /**< An approximation (CALCULATED date1) */
+ DV_ESTIMATED, /**< An approximation (ESTIMATED date1) */
+ /* Other */
+ DV_INTERPRETED, /**< INTERPRETED date1 FROM phrase */
+ DV_PHRASE /**< phrase */
+};
+
+ /** \brief Date value type */
+typedef enum _Date_value_type Date_value_type;
+
+ /** \brief Date input type for gedcom_normalize_date
+
+ See explanation for gedcom_normalize_date().
+ */
+enum _Date_input {
+ DI_FROM_STRINGS,
+ /**< compute from date#day_str, date#month_str and date#year_str */
+ DI_FROM_NUMBERS,
+ /**< compute from date#day, date#month, date#year and date#year_type */
+ DI_FROM_SDN
+ /**< compute from date#type, date#sdn1 and date#sdn2 */
+};
+
+ /** \brief Date input type for gedcom_normalize_date */
+typedef enum _Date_input Date_input;
+
+ /** \brief Parsed date
+
+ This struct describes exactly one date. It contains the string
+ representation, the numeric representation and the representation using
+ serial day numbers (aka Julian days).
+
+ It is possible that the #year_str is given as e.g. "1677/78". This is
+ coming from a date in a so called "annunciation style", where the year
+ began on 25 March: "20 March 1677/78" is 20 March 1677 in "annunciation
+ style" and 20 March 1678 in "circumcision style" (the current style).
+ See calendar overview (LINK TBD).
+
+ In this case, the #year will contain the "circumcision style" year (1678
+ in the example), and #year_type will be YEAR_DOUBLE. Normal dates will
+ have a #year_type equal to YEAR_SINGLE.
+
+ Finally, the last three fields (#type, #sdn1 and #sdn2) are probably
+ the most interesting values
+ for applications that want to process dates. Basically, the date is
+ converted to a serial day number (aka Julian day), which is the unique
+ day number since November 25, 4714 BC in the Gregorian calendar. The
+ advantage of these day numbers is that they are unique and independent
+ of the calendar system. Furthermore, date differences can just be
+ computed by subtracting the serial day numbers.
+
+ However, since dates in GEDCOM are not necessarily exact (e.g. "MAR
+ 1990"), it is not possible to represent all GEDCOM dates with 1 serial
+ day number. Two cases can be distinguished:
+
+ - <b>Exact dates</b> (e.g. "25 MAR 1990"):\n\n
+ These are represented by a serial day number in #sdn1 and a
+ #type equal to DATE_EXACT.
+
+ - <b>Incomplete dates</b> (e.g. "MAR 1990"):\n\n
+ These are represented by 2 serial day numbers (#sdn1 and #sdn2)
+ and a #type equal to DATE_BOUNDED.\n\n
+ For example, the Gregorian date "MAR 1990" is represented by the
+ serial day numbers for "1 MAR 1990" and "31 MAR 1990", and the
+ Gregorian date "1990" is represented by the serial day numbers
+ for "1 JAN 1990" and "31 DEC 1990". Similarly for the other
+ calendar types.
+ */