off by one calendar day when using create_date in search

[Jason Etheridge]

In the TPAC, entering a search like this:

create_date(2013-10-01,2013-10-15)

will produce SQL that includes a clause like this:

AND bre.create_date BETWEEN $_24259$2013-10-01T00:00:00$_24259$ AND $_24259$2013-10-15T00:00:00$_24259$

So we're actually omitting records created on 2013-10-15, which goes against expectations.

[Lebbeous Fogle-Weekley (lebbeous)]

This seems to fix it in my tests:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/senator/bre_dates_not_timestamps

[Lebbeous Fogle-Weekley (lebbeous)]

(There are enough milestones available for bug targeting right now to confuse me. If 2.5.0 and 2.4.4 are inappropriate choices, just change them.)

[Mike Rylander (mrylander)]

My concern with that has to do with indexing -- or, more specifically, the likely non-use of the existing index on biblio.record_entry.create_date. The on there may not be used at all, of course, in which case swapping it for a DATE-granular index would be better. Analysis of a production site (pg_statio_user_indexes, IIRC) would be in order to decide, IMO.

[Ben Shum (bshum)]

Mike mentions adding a new index in comment #3.

Something to fix for 2.7.1!

[Kathy Lussier (klussier)]

Removing the pullrequest tag since work is ongoing.

[Ben Shum (bshum)]

Removing milestones while work is still ongoing for this issue.