Dates in search window should be converted to UTC before searching

[dstillman]

Currently dates are passed directly to the DB, which has dates stored in UTC. Users, however, see localized dates in the metadata fields. If they searched for the same date they saw in the metadata panel, they wouldn't find the item.

[dstillman]

(In [858]) Much improved date handling in searches and autocomplete

Fixes #338, Dates in search window should be converted to UTC before searching
Addresses #220, Add a more friendly way to enter dates in search window and accessDate field

• Unless passed a full datetime, the search system automatically parses the string with strToDate(), so one can search for an accessDate, etc., using a freeform phrase. It will use the SQL parts where available and also search for remaining words individually, so "November 6, 2006" will find '2006-10-06 Nov. 6 2006' and "Summer 2006" will find '2006-00-00 Summer 2006". It will also properly handle SQL parts, so "August 2006" in the is/isNot operator will use "LIKE '2006-08-'" (underscore being the single-character wildcard) and isBefore will use '2006-08-00'

• Stored UTC dates are converted to localtime in the search system when searching on just a date part, since otherwise searching for a local date with a UTC timestamp after midnight would be unsuccessful

• Date field autocomplete is now disabled in the search dialog, but on the off-chance that it's used somewhere, the autocomplete will now return just the user part of a multipart date field

• Access date autocomplete only returns date, not datetime

• Fix for Date Added and Date Modified showing as UTC

• Date.isSQLDateTime()

Known issues:

• accessDate field in metadata pane still requires SQL format

• Proper parsing of search dates with no years (e.g. searching for "August 25") depends on #389, "Date.strToDate() should return available parts even if no year"