Date Input & Output Options

[Uncle Buddy]

For no reason whatsoever, genieware tends to limit the ways dates can be input while giving the user the option of displaying dates in ways that will be ambiguous to some other users who try to read their output. This is exactly backwards.

Dates can be input in a great variety of ways without causing anyone a problem as long as the code is written to provide this flexibility. Users should not have to think about which date entry style they have to use. Any date entry style should be recognized and if any particular input is not recognizable, a simple dialog can pop up for clarification of that input only.

But when it comes to displaying dates, certain formats should not be an option. Especially the ambiguous alternates "10-12-1884" and "12-10-1884" which each have opposite meanings to Americans who put the month first and Europeans who put the day first. ISO format puts the largest time period first so it's always year-month-day, as in "1884-10-12" which is unambiguously "Oct. 12, 1884". So ISO format is allowed for output.

The only other unambiguous date display formats are the ones that spell out all or part of the month.

In regards to date input, the user should be told that if he spells the month out or spells out the unique first letters of the month, or if he uses the ISO format, he will never see a confirmation dialog. The software should recognize the months as soon as the user has typed anything from this list: "ja, f, mar, ap, may, jun, jul, au, s, o, n, d". There's no reason to make the user type any more than that. Also if the user mis-spells the month but gets the first part right, the month should be recognized with no further ado. For example, you should be able to type "apricot" or "autumn" and have these strings recognized as April or August. This final feature came accidentally in Python and I decided to keep it in case it's helpful when it comes time to translate Treebard into other languages. Also, I enjoy typing "ogre" and seeing it display as "October".

Treebard will allow the user to enter date parts in any order whatsoever, including prefixes and suffixes such as "est, abt, AD, BC" etc., while making it impossible to enter a bad date into the database. The user wants to keep his mind on genealogy, not on the software he's trying to use. All dates will be stored in ISO format no matter what input or output format is used. The key to this system is to treat input, storage, and output formats completely separately, with a different set of rules for each. Input date format is very free, storage is always ISO, and output is restricted to unambiguous formats.

The most restrictive aspect of date entry will be that the same separator has to be used throughout any given date entry. For example, "est 14 12 1850 ad" will be recognized but "est 14-12-1850" will not. To keep from bloating the code, the line has to be drawn somewhere on the user's freedom to enter dates in any conceivable way. The entry "12*abt*14*ad*1850" is allowed and will be stored in ISO format and then displayed in whatever format the user chooses. The next date can be typed with slashes or dashes or spaces for a delimiter as long as any given date uses only one character as a delimiter.

Date parts can be separated from each other with any character from this list: "dot, slash, dash, space, asterisk".

[Uncle Buddy]

I had to change minimum recognizable input for October and November to 'oc' and 'no' to avoid confusion with OS and NS which refer to new style and old style dates. More on new style and old style dates below.

Abbreviations other than months have to be spelled out (e.g. like 'est', 'abt'; not like 'estimated', 'about'), but not case-sensitively. Enter date parts as you think of them, in any order. '1942 est ad 28 2' will be displayed as 'est. February 28, 1942 AD' or some other user-selected format. In the case of '2 12 1942' Treebard would pop up a dialog so the user could say which is the month and which is the day, but entering 'feb 1942 12' or 'dec 1942 2' would prevent the dialog from popping up.

I said in the last post that entering dates in ISO format '1942-12-2' would prevent the dialog from popping up but this is not true. Because the user has so much flexibility, Treebard needs to see a word month to be sure. Even 'March 2 12' would open the dialog so the user can say whether that's March 2 in the year 12 or March 12 in the year 2. A lot of time has been consumed creating a comprehensive validation for dates in the first century that will never be needed by most genealogists.

I'm getting ready to start on range and span. A date span is 'from date 1 to date 2'. This is used for long-term attributes such as a career. A date range is used when an exact date for a discrete event hasn't been pinpointed. It means 'between date 1 and date 2'. Ranges and spans will involve compound dates. Two dates will have to be entered and both validated. Treebard doesn't allow impossible dates to be entered into the database.

Like abbreviations, there won't be much flexibility on how ranges and spans are entered. The user should not be given a lot of flexibility in edge cases, it bloats the code for little cause. The main date entry is loose as a goose, it gives the user a lot of freedom so ordinary dates can be entered very quickly. When entering a range, input might be something like '1888 1 13 and 1885 12 3' which would be displayed, for example, as 'betw. 3 Dec 1885 and 13 Jan 1888'. A span might be input like '1799 to 1756' and would display something like 'fr. 1756 to 1799'. Treebard can correct the order of the two dates for display but I don't think the user should have a lot of flexibility to enter date qualifiers in more than one way. At some point, too much freedom is confusing. And I want to move on to the next topic, which will be autofill entry of place names.

I don't look forward to dealing with old style dates. Personally the topic doesn't interest me since most people will never have an accurate date to input for events that far back anyway. Documents for most people's further-back ancestors are limited to census and/or a few odd scraps of trivia. There are exceptions but a lot of people just make things up or fill in the blanks with no real evidence so they can pretend they've traced themselves back to Adam and Eve.

The real problem with old style and new style dates, besides the fact that they are ugly, is that each country adopted the new calendar at a different point in history, a different year. So the software can be set to display compound dates that would be accurate for a certain country but not for every country.

Basically I don't find the topic interesting and most people don't care if their 19th great-grandparents got married in 1681 or 1682. How many really old gravestones show accurate birth dates? Even social security records are often wrong by one year, and ages on census records are a joke. Not always, but a person's calculated birth year based on recorded age can vary by more than ten years from one census decade to another. Genealogy is supposed to be fun and I can't see pretending at accuracy that doesn't exist, just so we can look at ugly compound dates. A few purists will disagree strongly, which is fine, it's their job. If Treebard is forked someone can add a compound date display functionality for old style dates. To be accurate, it seems to me that the code would have to be told what country the event takes place in so that compound dates are only displayed for the correct spans of history.

The reason that birth years are so often wrong by one year is that people will subtract years without taking days and months into account. I've already written one date calculator which works pretty well but it was a long time ago so I won't like the code next time I see it and will want to write it over from scratch.

[Uncle Buddy]

The date entry input code is pretty much done for now. It amounts to almost 1600 lines of code. It includes a widget class that looks like a static display because I don't like the look of a bunch of empty white boxes on a page. That's a table that begs to be filled out and it's unfriendly-looking to the user. It looks like work. The user will fill out dates as he finds them by entering information into a cell of the events table that looks like background but can take a value. A validation class goes over each date entered with a fine-tooth comb and prevents any bad (impossible) dates from being saved in the database, such as Feb 31. Good dates are OK'd by saving them in the database and making the entry in the table read-only. To change the date, the read-only entry can be double- or triple-clicked to make it editable again.

The user can input dates in a horrendous variety of ways, and that's one reason why it took me so long. I'd written a date validator before but I started over around Feb. 6 with the intention of giving the user more freedom than he needs in how he enters a date, while limiting date display to formats that are not ambiguous. The result will go on a preferences tab that allows the user to select formats in nine different areas of date formatting and test many styles of input to see how it works without effecting his data. It's all easy to use and self-explanatory but there are also status bar labels, tooltips, and coming tomorrow, a right-click context-sensitive help menu.

I thought I'd been working on this for at least three months so was surprised when I saw I only started on it about six weeks ago. I started over three times, I think it was. The hardest part was figuring out a clean way to code the compound date section. For example, if you have a span ("from Feb 3, 1928 to Feb 20, 1928") or a range ("between March 1928 and January 1930"), two dates have to be validated separately and then when it's time to combine them and display them as one date, the code has to be kept simple or it's impossible to read, extend or maintain. I finally figured it out and using Python classes was a big help. I hated classes for a long time but once I learned how to pass values and return values in functions, accomplishing the same thing with classes (Python instance variables) made everything so much easier.

I'm still not an OOPer for those who know what object-oriented-programming is, but I now know the joy of writing a class and being able to instantiate it anywhere instead of going over a bunch of loose code and trying to figure out what to copy where. I read somewhere and agree that classes should be used where there is not only procedure being done but state being saved and modified. And the main point is that classes can be overused by writing classes for everything, but they are best used for code that would otherwise be copied over and over. A few months ago I thought I hated Python classes and the "self" keyword but now I love them both because this module got so complicated without them that I couldn't get to the end of the task without the easy-to-use instance variable marked by "self".

Attachments: