Github user dsmiley commented on the issue:
https://github.com/apache/lucene-solr/pull/428
It's coming along great. Please add the following comment at the top of
our parsing method:
```
// see https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8177021
which is fixed in Java 9.
// The upshot is that trying to use parse(Instant::from) is unreliable
in the event that
// the input string contains a timezone/offset that differs from the
"override zone"
// (which we configure in DEFAULT_TIME_ZONE). Besides, we need the
code below which handles
// the optionality of time. Were it not for that, we truly could do
formatter.parse(Instant::from).
```
Ok still, there is I think one last remaining task. Search for
ParseDateFieldUpdateProcessorFactory across the codebase and you will find many
references to include ".adoc" (in the ref guide) and in many solrconfig files
to include the default one. Most/all of them have a particular set of
patterns, and they are out of date because they have "Z" and not "z". I
discovered this due to a failing test -- TestCloudSchemaless which uses one of
these test files. But moreover now that we're on java.time API we can be
smarter about pattern specifications by leveraging optional sections (open
bracket). For example, parse-date-UTC-defaultTimeZone-no-run-processor in our
test can be reduced to this:
```
<arr name="format">
<str>yyyy-MM-dd'T'HH:mm[:ss[.SSS]][z</str>
<str>yyyy-MM-dd'T'HH:mm[:ss[,SSS]][z</str>
<str>yyyy-MM-dd HH:mm[:ss[.SSS]][z</str>
<str>yyyy-MM-dd HH:mm[:ss[,SSS]][z</str>
<str>yyyy-MM-dd</str>
<!-- extra ones not in the standard set above -->
<str>yyyy-MM-dd hh:mm[ ]a</str>
<str>EEE MMM dd HH:mm:ss ZZZ yyyy</str>
<str>EEE MMM dd HH:mm:ss yyyy z</str>
<str>EEE MMM dd HH:mm:ss yyyy</str>
<str>EEE, dd MMM yyyy HH:mm:ss z</str>
<str>EEEE, dd-MMM-yy HH:mm:ss z</str>
<str>EEEE, MMMM dd, yyyy</str>
<str>MMMM dd, yyyy</str>
<str>MMM. dd, yyyy</str>
</arr>
```
(which has not only the documented/recommended set but some additional
ones). I don't mean to say add the extra patterns on the bottom here to all
those places, just the ones on top (5 patterns). Fewer patterns is faster too
-- fewer doomed parsing attempts, fewer exceptions.
When updating testParseDateFormats we may want to forgo the duplication of
putting the pattern in there -- the input samples alone is fine.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
