#431: WebSearch: fix test case searching by date 1976-04-01 and t dog
------------------------+----------------------
Reporter: simko | Owner: valkyrie
Type: defect | Status: assigned
Priority: critical | Milestone: v1.0
Component: WebSearch | Version:
Resolution: | Keywords:
------------------------+----------------------
Comment (by jblayloc):
It may take many moons before dateutil patches are accepted upstream
and, more to the point, before they land in mainstream GNU/Linux
distributions like Debian Stable. I think we should fix it
internally. It would not be very nice to ask all Invenio/INSPIRE
instances to recompile their dateutil dependency. If at all possible,
we'd better avoid this.
I have multiple problems with this.
It may take many moons before dateutil patches are accepted upstream
and, more to the point, before they land in mainstream GNU/Linux
distributions like Debian Stable.
Since when have we cared whether things are packaged in any particular
distribution? And why should we? I count at least 5 packages that I have
to build myself to do an installation on SLC5; it makes no difference to
me whether I have one more to do.
If we care about packaging so much, we should be packaging Invenio and its
dependencies (in which case, again, it's a non-issue.)
I think we should fix it internally.
I have been given (and transitively, Valkyrie has been given) a __hard
requirement__ that SPIRES syntax support dates in the same way that SPIRES
does. To me, this looks frankly impossible to do in Python, unless we are
to write our own date parsing library from scratch and put more work into
it than has currently gone into the rest of our parsing infrastructure
(put together). Dates are hard. I don't want to write an
internationalized date parsing library. `python-dateutil`, `mxdatetime`,
and everything else I've examined (including, for the sake of comparison,
the gold standard Perl's `Date::Manip`) are fundamentally broken (if your
goal is SPIRES style handling) because they require the complete
specification of all dates. There is no mechanism for the date parsers in
these libraries or any other that I've heard of to automatically promote
searches of the form "May" to deltas.
Massaging dates in arbitrary input formats into a reference format so that
we can decide whether to turn them into deltas is an equivalent problem to
writing an internationalized date parser from scratch.
So, the right place to fix this problem is the date parser.
You've yet to suggest a solution that seems tractable given this hard
requirement for SPIRES style date handling. We would be happy to have
one.
In this and other messages you seem to come just short of advocating that
we give up on this requirement and use only ISO dates (plus yesterday,
last week, etc.) everywhere. If this is what you want, you're not going
to get it by hassling Valkyrie and I. Talk to Heath and Annette and
Travis. We would be very happy to conform to simplified requirements.
It would not be very nice to ask all Invenio/INSPIRE instances to
recompile their dateutil dependency. If at all possible, we'd better
avoid this.
I don't understand why. I thought that it was clear from Valkyrie's
comments that you'll only need a patched python-dateutil to get what
SPIRES calls working date parsing. To get what Invenio calls working date
parsing (ie, no indefinite ranges and ISO dates only) we'll have something
banged out using regexp's in the next branch push.
Also I should point out that dateutil is all python; there should be
nothing to compile. I haven't tried, but you should be able to apply the
patch in place to a running copy of the code (ie, a monkey patch). I'd be
happy to work out the mechanics and post them to the wiki.
--
Ticket URL: <http://invenio-software.org/ticket/431#comment:16>
Invenio <http://invenio-software.org>
