[
https://issues.apache.org/jira/browse/SOLR-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565637#action_12565637
]
patrick o'leary commented on SOLR-470:
--------------------------------------
parseMath returns a Date object that's formated to the SDF in the LocalThread
that's fine /scratch last un-caffeinated comment.
I think the root of the problem is any call to 'toInternal(String)' with a
string that end's in 'Z' is indexed directly, which now means there can be
multiple date formats represented internally in the index.
But in saying that, I'm guessing that a Field does not necessarily have to be
indexed to call toObject.
What would be nice is to switch from using SimpleDateFormat to
org.apache.commons.lang.time.DateUtils
Which supports parseDate(String str, String[] parsePatterns) , where multiple
patterns can be tried, and using
init to allow users supply their own patterns.
And then using org.apache.commons.lang.time.FastDateFormat to represent the
dates internally.
Both of these are thread safe, which should make a Flexible DateField a lot
easier to implement without
much over head.
> DateField throws error on iso8601 date
> --------------------------------------
>
> Key: SOLR-470
> URL: https://issues.apache.org/jira/browse/SOLR-470
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 1.3
> Reporter: patrick o'leary
> Assignee: Hoss Man
> Fix For: 1.3
>
>
> A correct iso 8601 date 2006-01-01T12:01:00Z throws an error.
> Unparseable date: "2006-01-01T12:01:00Z" at
> org.apache.solr.schema.DateField.toObject(DateField.java:173) at
> org.apache.solr.schema.DateField.toObject(DateField.java:83)
> The ThreadLocalDateFormat requires fractional seconds
> "yyyy-MM-dd'T'HH:mm:ss.SSS"
> to parse with simple date format. Where as the jdoc states their optional.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
