[jira] [Updated] (SOLR-8904) Switch from SimpleDateFormat to Java 8 DateTimeFormatter.ISO_INSTANT

["David Smiley (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Smiley updated SOLR-8904:
-------------------------------
    Attachment: SOLR_8904_switch_from_SimpleDateFormat_to_Instant_parse_and_format.patch

Here's the patch.  Instead of referencing DateTimeFormatter in a bunch of places, I opted for the even more concise Instant.toString().  So DTF is only used in maybe a couple places.  DateFormatUtil is gone.

This patch also weens _some_ callers of DateUtil to Instant.toString so long as that format was what was required based on the code.  But DateUtil itself and some of its callers is being left to SOLR-8903.

I'm running tests yet again.  I had also run precommit.

> Switch from SimpleDateFormat to Java 8 DateTimeFormatter.ISO_INSTANT
> --------------------------------------------------------------------
>
>                 Key: SOLR-8904
>                 URL: https://issues.apache.org/jira/browse/SOLR-8904
>             Project: Solr
>          Issue Type: Task
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 6.0
>
>         Attachments: SOLR_8904_switch_from_SimpleDateFormat_to_Instant_parse_and_format.patch
>
>
> I'd like to move Solr away from SimpleDateFormat to Java 8's java.time.formatter.DateTimeFormatter API, particularly using simply ISO_INSTANT without any custom rules.  This especially involves our DateFormatUtil class in Solr core, but also involves DateUtil (I filed SOLR-8903 to deal with additional delete/move/deprecations for that one).
> In particular, there's {{new Date(Instant.parse(d).toEpochMilli())}} for parsing and {{DateTimeFormatter.ISO_INSTANT.format(d.toInstant())}} for formatting.  Simple & thread-safe!
> I want to simply cut over completely without having special custom rules.  There are differences in how ISO_INSTANT does things:
> * Formatting: Milliseconds are 0 padded to 3 digits if the milliseconds is non-zero.  Thus 30 milliseconds will have ".030" added on.  Our current formatting code emits ".03".
> * Dates with years after '9999' (i.e. 10000 and beyond, >= 5 digit years):  ISO_INSTANT strictly demands a leading '\+' -- it is formatted with a "\+" and if such a year is parsed it *must* have a "\+" or there is an exception.  SimpleDateFormatter requires the opposite -- no '+' and and if you tried to give it one, it would throw an exception.  
> * Currently we don't support negative years (resulting in invisible errors mostly!).  ISO_INSTANT supports this!
> In addition, DateFormatUtil.parseDate currently allows the trailing 'Z' to be optional, but the only caller that could exploit this is the analytics module.  I'd like to remove the optional-ness of 'Z' and inline this method away to {{new Date(Instant.parse(d).toEpochMilli())}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org