DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23685>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23685 DateField support for pre-1970 dates Summary: DateField support for pre-1970 dates Product: Lucene Version: CVS Nightly - Specify date in submission Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've attached a zip file that contains a set of changes (additions and patches) to enable pre 1970 date support for DateField. (I'm working on an app that needs to index historical dates...) I don't know that this is necessarily the best way to support pre 1970 dates, but its something I've been working with and thought it might work in general... I've added a class (DateFieldDefinition) that discribes how a DateField should be interpreted. (How far plus/minus of 1970 dates should be supported, and what resolution of time differences between dates should be supported.) There are two "well-known" DateFieldDefintions DateFieldDefinition.DEFAULT_DATE_DEF and DateFieldDefinition.HISTORICAL_DATE_DEF. DEFAULT_DATE_DEF is what is currently in place in DateField, i.e. no pre-1970 dates, resolution on date differences of a millisecond. HISTORICAL_DATE_DEF supports dates in the range of 1970 +/- 5,000 years, with a resolution of date differences of a day. I've also added an interface FieldStrategy that describes whether a field is a DateField and which DateFieldDefinition to use for a given field. I modified QueryParser.jj to make use of a FieldStrategy if its available when parsing term queries, range queries and fuzzy queries. QueryParser has been modified to include the following new public methods (existing methods without the FieldStrategy argument remain): static public Query parse(String query, String field, Analyzer analzer, FieldStrategy strategy); public QueryParser(String field, Analyzer analyzer, FieldStrategy strategy); In the absence of a FieldStategy, Queryparser behaves as it does currently with one exception, range queries no longer automatically attempt to treat the field as a date field. (This could be changed, but I'm a fan of parallel semantics between similar functions.) I've added an implementation of FieldStategy, more for illustrative purpose and use in test cases. It assumes that any field that contains '.date' in the name is a DateField and that all dates should be handled with the default definition. Finally, I've modified fuzzy search on date to pick up hits based on how far in time one date is from the query target date rather than on the edit distance of the string representations. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
