[ https://issues.apache.org/jira/browse/SOLR-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218565#comment-15218565 ]
ASF subversion and git services commented on SOLR-8904: ------------------------------------------------------- Commit 72f5eac2c5e7fb743f166fb3c1b25e73078ebdbe in lucene-solr's branch refs/heads/branch_6x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=72f5eac ] SOLR-8904: switch from SimpleDateFormat to Instant.parse and format. [value] and ms() and contrib/analytics now call DateMathParser to parse. DateFormatUtil is now removed. (cherry picked from commit 94c0423) (cherry picked from commit 39932f5) > 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.patch, SOLR_8904.patch, > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org