[
https://issues.apache.org/jira/browse/SOLR-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731957#action_12731957
]
David Smiley commented on SOLR-750:
-----------------------------------
Ignoring the long-gone circumstances in which I encountered and reported this
issue originally...
I do feel strongly that Solr shouldn't force me to specify a Z when Solr
doesn't really have any time zone support. And as such it shouldn't emit the
"Z" in date output either. If I'm using Solr and want to feed it dates in a
particular time zone, or perhaps a local-time of day, and clients expect this,
then why should Solr force me to specify a timezone? I find it irritating.
> DateField.parseMath doesn't handle non-existent Z
> -------------------------------------------------
>
> Key: SOLR-750
> URL: https://issues.apache.org/jira/browse/SOLR-750
> Project: Solr
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: David Smiley
> Priority: Minor
> Attachments: SOLR-750_DateField_no_Z.patch
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> I've run into situations when trying to use SOLR-540 (wildcard highlight
> spec) such that if attempts to highlight a date field, I get a stack trace
> from DateField.parseMath puking because there isn't a "Z" at the end of an
> otherwise good date-time string. It was very easy to fix the code to make it
> react gracefully to no Z. Attached is the patch. This bug isn't really
> related to SOLR-540 so please apply it without waiting for 540.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
