A "loose date" data type.  This is commonly needed in databases that deal with historical or prospective date information that requires accuracy even if that accuracy is only approximate. For instance, if the best you know is "approximately March 1985", you can't put "15 Mar 1985", since that would give the false impression you know the exact date.

The problem with using a string field for such data is that you can't perform any date math. Databases that need this data type are litigation databases, historical databases, authors' research notes, genealogy, collections of newspaper and similar articles, photo collections.

Common formats and how they would generally be treated for date-math purposes are as follows:

Note	Entry	Meaning	Treat as
(1)	Abt/ca/approx May 1928	Available information produces an approximate date	1 May 1928
(2)	est 1928 / est May 1928	Estimate based on general information	1 May 1928
--	29 Feb 1921 / 31 Mar 2002	Project rules require "enter as written"	nearest valid prior date, here 28 Feb or 30 Mar
--	May 1928	Sometime in May	1 May 1928
(3)	bef May 1928	Before May 1928	30 Apr 1928 (or 1 May 1928)
--	poss/prob May 1928	Possibly, probably May 1928	1 May 1928
--	May 1928 ? / May 1928(?)	Possibly, probably May 1928	1 May 1928
(3)	aft May 1928	After May 1928	1 June 1928 (or 31 May 1928)
--	7-10 May 1928	The period May 7 thru May 10	7 May 1928
--	1928	Sometime in 1928	1 Jan 1928

Notes:

(1) Often available information produces an approximate date.  For instance, census records on a specific date often include the subject's age, which allows calculating an "about" birth year.

(2) The difference between "about" and "est[imate]" is that an estimate uses general, not specific information. For instance, if someone is born in 1950, their parents probably were in their early 20's, so an estimate would be that the parents were born around 1927. With life expectancy being around 72 (using a common genealogy approximation), the parents probably died around 1999.

"About/ca" basically says, "I don't know the exact value but available information specific to this case lets me set some likely limits." "Estimate" basically says, "This is an educated guess based on general information."

(3) Because by the approximate nature of the input data the result can only be approximate, oftentimes a "before" or "after" is ignored. For instance, when Ancestry.com calculates age, "bef May 1928" will be treated as "May 1928", not "Apr 1928".

---

As you can see, for date math with a "loose date" the basic rule is, "If a date isn't specified, use the first day of the month/year." The exception would be "before" or "after".  Also, there is a fairly limited number of widely-accepted qualifiers, so parsing for those would not be overly complex:

• abt / about (I have only seen "abt" used on Ancestry.)
• aft / after
• approx / approximately
• bef / before
• ca / circa
• poss / possibly
• prob / probably
• ? / (?)

Although the field can take other text, any other text (such as "maybe", "unk" or "tbd" for "to be determined") produces an error in date math--not a crash, but something like ########.

Let me 2nd the loose data type request.  I use a Sesame database to track historical research and a date field as described would be invaluable.  The same would be true for my law firm's case management application.  Having said that, the idea has gotten me thinking (a dangerous and not so valuable event).  For now, I think it might be possible to mirror a loose data function by having a "shadow" date field incorporate infomation from a text field that is populated by dropdowns or @calendar plus a text dropdown with the appropriate prefix. Whatever is entered would then be parsed by programming and entered into the strict date field from which all sorting is done. 

It's great that a user can work with a batch (in Add mode) directly after importing from a text file.

If possible, being able to SORT and use Table mode on the new batch (directly after importing) would be handy.

Thanks, as always, for a great product!

Steve