[
https://issues.apache.org/jira/browse/SOLR-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16553789#comment-16553789
]
David Smiley commented on SOLR-12561:
-------------------------------------
Updated patch:
* updated the ref guide
* optimized away one of the formats by putting the timezone in an optional
element. Added a test for this.
* added a test for missing 'T' case in ISO-8601 (ish) format
* enhanced missing time check when formatting, which will find the "hh" likely
user config error
* Eagerly checks the patterns when the formats are built (throwing an
exception), thus the user configuring "date.formats" eagerly gets notified of
the config error instead of silently ignoring the pattern or date at runtime.
Just to be safe I'll put this stuff in 8.0/master. I added CHANGES.txt stuff
in the patch including upgrade info.
> Port ExtractionDateUtil to java.time API
> ----------------------------------------
>
> Key: SOLR-12561
> URL: https://issues.apache.org/jira/browse/SOLR-12561
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Solr Cell (Tika extraction)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Minor
> Fix For: master (8.0)
>
> Attachments: SOLR-12561.patch, SOLR-12561.patch, SOLR-12561.patch
>
>
> The ExtractionDateUtil class in the extraction contrib uses
> SimpleDateFormatter. The Java 8 java.time API is superior; you can find
> articles out there why. One thing that comes to mind is less timezone
> bugginess – SOLR-10243. Although the API may be a bit baroque IMO
> (over-engineered). Here I'd like to switch over the API and furthermore have
> the patterns be pre-parsed so that at runtime we don't need to re-parse the
> patterns.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
