As for whether there’s value in saying only the day and the month, I’m wondering how often it actually shows up. In theory, yes, it’s important. In practice? I don’t know. It’s possible that you could come across a record saying Great Grandpa Jones’s birthday was 16 October, but without specifying a year. But how often do those kinds of things come up? Part of me says, “If it’s quite uncommon, don’t worry about it. 80% majority rules.” But then the perfectionist in me hollers back, “What?!? It had better be as thorough as you can make it!”

I’m thinking about the possible issue of negative years (B.C., that is). Granted, most genealogists probably haven’t gotten back that far (and perhaps never will), but then again you have Chinese lines that go back thousands and thousands of years. Hmm…

Which brings us to the calendar question — it seems like the only way to do it is store dates internally in a single set calendar system, and then translate them to and from whatever the user wants to use (Chinese, Jewish, Revolutionary, etc.). I’ll have to look into it in more depth to see how different the other calendars are. Whatever the solution is, it needs to be easy for the user to use.

I want to store the dates in two parts: the date, and a qualifier. The date can be just a year, a year and month, or a year month and day (time could also be included but probably not). The point is that it goes from general to specific (although there may be value to only saying the day and month?). Anyhow, then the qualifier is “exact,” “about,” “before,” “after,” or any number of others.

Then I’ll store the dates as a string of the form YYYYMMDD (partial dates would be YYYY and YYYYMM). Then it’s a simple string search to find date ranges. For my implementaton I’m using Lucene to index the data, which does dates like this anyhow.