[
https://issues.apache.org/jira/browse/SOLR-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-470:
--------------------------
Attachment: SOLR-470.patch
checkpoint ... better test cases that take into account SOLR-552 as well.
This still isn't completed because it doesn't deal with formating correctly
(see failing test cases) ... attaching in case i get hit by a bus before i have
time to work on it again.
in this approach, i'm attempting to make the parsing "forgiving" of trailing
zeros in the millis, but strict about ensuring that the indexed form is always
the canonical per the docs.
As a result, i introduced a LegacyDateField for people who relied on the old
broken behavior that anything ending with a Z was "ok"
Reminder to self: if applying patch to commit, do an "svn copy DateField.java
LegacyDateField.java; rm LegacyDateField.java" before applying patch.
> 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
>
> Attachments: SOLR-470.patch, SOLR-470.patch, SOLR-470.patch
>
>
> 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.
