consider a more robust model for dates

[ianstiles]

Overloading Date with a value of "May 1863 - Jun 1864" is a burdened concept. When needed, which only seems to apply to waypoint time spans and collection coverage, then we should have a DateRange object that contains two Date objects.

We should consider the Date invalid if it includes a text string incorporating a range.

[stoicflame]

We could certainly model a date range but personally I don't like the idea because of the significant complexity that it would add to the model. I would much prefer to refer to (create, if necessary) a standard for date values such that date ranges can be reliably encoded into a string.

The complexity comes when you ask yourself what resources need to be able to support a date range and how to apply a date range to those resources. Do these resources have a separate property for the date range? Or do you model the Date object to accept a range? What do the objects look like?

And then you're already down the slippery slope of not only date ranges, but approximate dates, and dates of different calendars, and multiple date intervals, and recurring dates, etc. Yuck. IMO, it's much simpler to keep the scope genealogical standard in the range of genealogical data and keep the date standardization efforts separate in a different standard.

[ttwetmore]

And there are two types of ranges (from ... to, meaning continuous; and between, meaning somewhere unknown in between). Plus there is exact, approximate, before, after, on or before, on or after, computed, interpreted, possibly, probably, and so on. For a genealogical application I believe you need all of these as part of the date concept. Not if you're just serving up census data, but definitely if you are dealing with more complex issues.

[stoicflame]

The following commentary was submitted by @ttwetmore, including it here for discussion.

The Date classes defined on the model diagrams seem too simple for genealogical applications. Here is a proto definition of a more complete date structure. This allows for exact and uncertain dates, partial, computed dates, date ranges (from/to or between), befores and afters.

enum Calendar {
  Julian = 1;
  Gregorian = 2;
}
enum DateType {
  Exact = 1;
  About = 2;
  Possibly = 3;
  Probably = 4;
  Before = 5;
  After = 6;
  OnOrBefore = 7;
  OnOrAfter = 8;
  Between = 9; // Uses two single dates.
  FromTo = 10; // Uses two single dates.
  Computed = 11;
  Interpreted = 12;
}
message SingleDate
{
  optional Calendar calendar = 1; //
  optional int32 day = 2;
  optional int32 month = 3;
  optional int32 year = 4;
}
message Date
{
  //The calender this date is from.
  // The type of this date.
  required DateType type = 1;
  // The date or the start date.
  optional SingleDate startDate = 2;
  // The end date, if any.
  optional SingleDate endDate = 3;
}

[stoicflame]

Please note the proposal at #88, particularly example 2, allowing for a to-be-defined standard that specifies a date as either (1) a typed literal string or (2) a separate date structure or (3) both.