[
https://issues.apache.org/jira/browse/SOLR-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15211932#comment-15211932
]
David Smiley commented on SOLR-8904:
------------------------------------
FYI Instant is the new replacement for Date in Java 8. This patch is just
about switching the parsing/formatting though; not to stop using Date.
Instant.toString() uses DateTimeFormatter.ISO_INSTANT, so you can be pretty
concise when formatting if you want to. Here's a code snippet (which I
modified a test for) to build a formatted date string to send to Solr for a
test specified variable number of minutes: {{ZonedDateTime.of(2016, 1, 1, 0,
MM, 0, 0, ZoneOffset.UTC).toInstant().toString()}} (MM was a variable in a test
method)
In case anyone reading this missed my warning of these changes to the dev list,
I did so:
http://mail-archives.apache.org/mod_mbox/lucene-dev/201603.mbox/%3cCABEwPvGyqu=uDq8ULVAM1t_VX2Qg3++MOsDCYb7rcY5N=xm...@mail.gmail.com%3e
No responses yet so I assume no issue with making a backwards incompatible
change like this for 6.0.
My tentative CHANGES.txt entry will be, this, under "Upgrading from Solr 5.x":
{noformat}
* Date-time parsing has been made more strict (based on Java 8
java.time.DateTimeFormatter.ISO_INSTANT),
but also now supports negative years. AD years with >= 5 digits must have a
leading '+' (formerly unsupported).
BC years must have a '-' (formerly unsupported). All parts of the format must
be padded with zeros to the left
(e.g. "01" for January, never "1"). All parts must be within valid maximum
boundaries (e.g. 67 seconds is now
invalid). Formatted times from Solr now have the milliseconds 3-digit padded
if non-zero.
{noformat}
And I'll add an entry below under "Other Changes", more succinct.
Still running tests...
> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
