[GitHub] lucene-solr issue #428: SOLR-12586: deprecate joda-time and use java.time in...

[dsmiley <gi...@git.apache.org>]

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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org