Date Entry

Topics: Feature Request
Dec 31, 2012 at 5:54 PM

The existing Family.Show date entry/display has multiple issues, such as:

  • Need to be able to enter approximate dates (e.g. "About 1850", "1848? 1849?", "1848-1850?", "After 1850", "Before 1850")
  • Need to be able to enter dates outside the Windows epoch (i.e. cannot be represented in a .NET Datetime object)
  • Separation of months, days, years and optional input for either
  • BCE and AD
  • Support for other cultures, dating systems

This is a potential issue when writing to/from GED or Familyx files.

[Transferred from Family.Show. Entered by BAbdulBaki]

For a number of older or deceased relatives, I only know the year they were born. It would be nice if all dates were split into separate fields for DMY. Thanks.

[Transferred from Family.Show.]

Input must be in US date format, but I'm not a US person.

"The DateTime value type represents dates and times with values ranging from 12:00:00 midnight, January 1, 0001 Anno Domini (Common Era) through 11:59:59 P.M., December 31, 9999 A.D. (C.E.) ... in the GregorianCalendar."
Why don't dates before 0/0/0000 work? There should be a BC/AD field (separate) to allow negative dates (stored as non-negative numbers obviously). The same is true for most other calendar types I would think. Separating the dates into individual components and then using a string formatter based on the regional settings should allow the date to be displayed correctly. The date stored in the Family.Show XML file SHOULD NOT be the regional setting formatted date. It should be the date components as entered by the user, and Family.Show should reconstruct the DISPLAY DATE based on the user settings. Thus, if the month was added for Gregorian calendar, but the user wants to display it in Hijri, the original entered date is not altered in the XML file.
JBTIBOR: I've been asking to separate all the date/time fields for a long time now since like you said, not all are always known. However, just because I'm asking to put the date/time functionality in a separate class does not mean we can't use built-in parsers. What I want from Family.Show is to be able to allow multiple date formats without having to recompile each time. However, the format used should be consistent throughout the screen. Basically, it should parse the data to make sure everyone is using the same date format. It would be useful if there was a default date and a default language for each person.

For example, I enter most of my family names in Arabic, but I use the Gregorian Calendar for birthdays. However, due to inter-country marriages and stuff, I do have names written in English. If I had a birthday for someone using the Hijri calendar, I should be able to enter that as the default and have Family.Show show it to me in Gregorian (assuming all fields are known). Since the Hijri calendar, for that one person, is the known date, it should always be stored in XML. However, the display can always change since most people wouldlike to see all names and dates in a consistent format. Not to mention, not all calendars can be translated to another one with only partial data available. Some can I believe, while others won't. Julian to Gregorian are fine with partials, Gregorian to Hijri are not.

Whether we use the built-in .NET format is irrelavent in my opinion. The class and XML needs to be redesigned to better support this. If no transformation is possible, then showing the information in the default locale would be preferable.

An option is to show the date as one string, but when it comes time to edit it, it breaks into its multiple components and calendar type. Thus, Gregorian and Hijri calendars can both be displayed when needed.
By locale I mean locale, i.e. the Hungarian date format is yyyy. mm. dd.

BAbdulBaki: String parsing is the worse solution, and there is no algorithm what could determine from a string the correct date. Note, that .Net already has parse method for DateTime.

The best solution would be to enter year, month and day in separate fields (allow empty/null for any field) and store it as entered, because I assume I'm not the only one who knows only partial dates in some cases. Sometimes I know only that somebody was born in year 1867, sometimes I know the month also, but definitely there are cases when the complete date is not known.

The second best solution is to use a DateTimePicker control, I assume WPF has some control of this kind.

Since the application claims to be localizable it must not be forgotten that numbers and dates have different format in different locales (i.e. the decimal separator is sometimes ',' - comma). The locale format must be applied on display and input as well. .Net takes care of this in case someone does not override this functionality.