This project has moved. For the latest updates, please go here.

"V1.0/Dublin" Spec - "Date Entry"

Topics: Project Discussion
Coordinator
Jan 9, 2013 at 5:01 PM
Edited Jan 25, 2013 at 12:20 AM

Family Lines - Functional Spec

Date Handling - "V1.0/Dublin" Release 

Author: Kevin Routley - V1.1 - 20130109

Summary

The Family.Show date handling has a number of problems. As genealogy dates are often approximate, using a .NET DateTime for date storage is too precise and limited. The goal of this feature will be to replace the existing date entry and persistence with a slightly more flexible system.

Scenarios

  • User needs to be able to enter a B.C. date.
  • User needs to be able to use approximate dates (About, Before, After).
  • User only knows a year, or month/year. User does not want to see "01/01/year" when they only know the year.
  • Because of their locale, the user prefers to enter dates in yyyymmdd order, not mmddyyyy.
  • Support an overriding "genealogy standard" format of dd-mmm-yyyy. 

Non-Goals

Date handling will not attempt to deal with the switch from the Julian calendar to the Gregorian calendar. I.e. when subtracting two dates, the impact of the calendar switch will be ignored.

In this release, supporting non-Gregorian calendars is optional. The date entry control and date class should be written so as not to disallow a calendar indicator. Research may be necessary to determine if valid values are different for day/month numbers in other calendars. Examples of "other" calendars would be Hebrew, Chinese, Hijri, etc.

We will assume that dates are consistent. I.e. when subtracting two dates the assumption is that both dates are in the same calendar.

Unless someone finds an exception, I believe we are using short dates only (not long dates such as "June 17, 1977"). TBD: the birthdays display has not been taken into account in this change.

This feature does not include handling of the GED DATE_CALENDAR tags, such as translation of month names to/from MONTH_HEBR tag. 

Overview

  1. Date class : create a new class to store date values.
  2. Date entry : create a custom control to visually support the new date class properties. Use the new control in the details panes.
  3. Date entry in grids: provide a popup date entry control for those grid fields where date editing is supported.
  4. Date filtering: the filtering system should not be impacted, "merely" uses the new date class for date matching.
  5. Date display : where a date is displayed, use the date class to output the date.
  6. Persistence : write the date properties to the familyx XML.
  7. Import/export : import/export GED intelligently. Be able to read "Family.Show" .familyx files and convert to the new class. 

 Details

 User Options:

The user should be able to indicate whether to hide AD/BC. This applies to date entry as well as date display. We will assume dates are AD if the indicator is hidden. TBD: consider an option to set AD or BC as default?

The user should be able to specify they wish to use the "genealogy standard" format of dd-mmm-yyyy. If selected, this impacts the display of components in the date entry control and the date output (overriding the locale setting).

Date Class:

1. A new date class will be necessary to store the date values.  The month, day, and year are separate properties. Support the approximate values (ABT/AFT/BEF) as per GED. Support AD/BC.

5. Wherever a date is currently displayed, use the date class to display the date. Display the BEF/ABT/AFT approximation indications as well as the AD/BC marker. The date display must be locale aware. E.g. "m/d/yyyy" in the US but "d/m/yyyy" in England, "d.m.yyyy" in Finland, etc.

TBD: determine if locale impacts the order of the different parts, e.g. "BEF 1/1878 AD" vs "AD 1.1878 BEF" in a right-to-left language?

TBS: Date calculations: the date class will need to support date comparisons. E.g. when using the 'Time' slider in the tree view, is "ABT 1878" after or before 1878? 1879? etc. How is age currently calculated?

TBD: calendar indication. Will it be easier to add a calendar choice now, or later? Is there a source of alternate calendar data we can leverage? What are the valid ranges for month, day or year in other calendars? Should we consider a user-definable calendar system?

TBD: other GED date 'keywords': FROM, TO, BET, AND, EST, CAL and INT. Where does the app show date ranges that might want to support these?

Persistence:

6. Output of the "new" FamilyLines .familyx format should be as easy as serializing the date class.

7. Import/export: When reading Family.Show .familyx files, it will be necessary to translate the (presumably) serialized DateTime object to the new date class. GED import/export will hopefully be simpler but will require changes.

Date Entry:

2. Date entry:

Create a new date entry control to allow the user to visually enter the new date properties [day, month, year, GED flag, AD/BC]. The date entry control must:

  1. respect the locale or user-option ordering of date components
  2. support the user option to hide the AD/BC indicator
  3. provide non-obstrusive hint labels or tooltips to help identify components
  4. validate when any component has been entered: a year is required; day is optional; month is optional unless a day is entered
  5. default to AD

The new date entry control replaces existing edit controls in the details areas. The current "hack" display of GED approximation flags should be removed. (images not supported).

3. Date entry in grids:

In the two data grids in the "Family Data" view, dates can currently be edited in-place (images not supported).

We'll need to display the new date format, and provide a mechanism to edit the date. TBD: The date editing will presumably take place in a popup which contains the new date entry control? The mechanism needs a "cancel" which means to leave the date unchanged.

4. Date filtering:

TBD: the GUI for filtering by date should not need to be changed. The filtering will need to use the date class for date comparison.