[
https://issues.apache.org/jira/browse/SOLR-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218626#comment-15218626
]
ASF subversion and git services commented on SOLR-8903:
-------------------------------------------------------
Commit 44e0ac38567e19465ebf74a160064b8a642ec6b6 in lucene-solr's branch
refs/heads/branch_6x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=44e0ac3 ]
SOLR-8903: Move SolrJ DateUtil to contrib/extraction as ExtractionDateUtil.
And removed obsolete methods.
(cherry picked from commit 5e5fd66)
> Move SolrJ DateUtil to Extraction module as ExtractionDateUtil
> --------------------------------------------------------------
>
> Key: SOLR-8903
> URL: https://issues.apache.org/jira/browse/SOLR-8903
> Project: Solr
> Issue Type: Task
> Components: SolrJ
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 6.0
>
> Attachments: SOLR_8903.patch, SOLR_8903_DateUtil_deprecate.patch
>
>
> SolrJ doesn't need a DateUtil class, particularly since we're on Java 8 and
> can simply use {{new Date(Instant.parse(d).toEpochMilli());}} for parsing and
> {{DateTimeFormatter.ISO_INSTANT.format(d.toInstant())}} for formatting. Yes,
> they are threadsafe. I propose that we deprecate DateUtil from SolrJ, or
> perhaps outright remove it from SolrJ for Solr 6. The only SolrJ calls into
> this class are to essentially use it to format or parse in the ISO standard
> format.
> I also think we should move it to the "extraction" (SolrCell) module and name
> it something like ExtractionDateUtil. See, this class has a parse method
> taking a list of formats, and there's a static list of them taken from
> HttpClient's DateUtil. DateUtil's original commit was SOLR-284 to be used by
> SolrCell, and SolrCell wants this feature. So I think it should move there.
> There are a few other uses:
> * Morphlines uses it, but morphlines depends on the extraction module so it
> could just as well access it if we move it there.
> * The ValueAugmenterFactory (a doc transformer). I really doubt whoever
> added it realized that DateUtil.parseDate would try a bunch of formats
> instead of only supporting the ISO canonical format. So I think we should
> just remove this reference.
> * DateFormatUtil.parseMathLenient falls back on this, and this method is in
> turn called by just one caller -- DateValueSourceParser, registered as
> {{ms}}. I don't think we need leniency in use of this function query; values
> given to ms should be computer generated in the ISO format.
> ----
> edit: added ms().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
