[
https://issues.apache.org/jira/browse/SOLR-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16526604#comment-16526604
]
David Smiley commented on SOLR-10243:
-------------------------------------
After spending the better part of a day debugging into the bowls of
SimpleDateFormat, I believe I found a JDK bug. I filled it to Oracle's Java bug
parade, which gave me internal review ID 9055824 and I'll be reached again in
the future after Oracle makes some decision on it. Here's the bug summary
description:
{quote}If SimpleDateFormat is configured with a pattern that allows for an
ambiguous timezone (like AKST in English Locale), and if that timezone is an
alias for the current platform/default timezone (such as America/Metlakatla),
then the input is parsed using the platform/default timezone. The objective of
many server Java applications is to be able to parse dates/times insensitive to
whatever the platform time zone may be but in this case it seems impossible.
My analysis using a debugger is that SimpleDateFormat line 1683 (of
subParseZoneString) contains what appears to be an optimization to avoid a
brute force time zone table lookup. This optimization is triggered when the
default time zone has a matching zone alias.
This bug was found in a randomized test for Apache Solr's "extraction" contrib
module: https://issues.apache.org/jira/browse/SOLR-10243
{quote}
I'll attach a demo source file that illustrates the problem.
w.r.t. Solr, I propose switching to the java.time API for this functionality.
> Fix TestExtractionDateUtil.testParseDate sporadic failures
> ----------------------------------------------------------
>
> Key: SOLR-10243
> URL: https://issues.apache.org/jira/browse/SOLR-10243
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
>
> Jenkins test failure:
> {{ant test -Dtestcase=TestExtractionDateUtil -Dtests.method=testParseDate
> -Dtests.seed=B72AC4792F31F74B -Dtests.slow=true -Dtests.locale=lv
> -Dtests.timezone=America/Metlakatla -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8}} It reproduces on 6x for me but not master.
> I reviewed this briefly and there seems to be a locale assumption in the test.
> 1 tests failed.
> FAILED:
> org.apache.solr.handler.extraction.TestExtractionDateUtil.testParseDate
> Error Message:
> Incorrect parsed timestamp: 1226583351000 != 1226579751000 (Thu Nov 13
> 04:35:51 AKST 2008)
> Stack Trace:
> java.lang.AssertionError: Incorrect parsed timestamp: 1226583351000 !=
> 1226579751000 (Thu Nov 13 04:35:51 AKST 2008)
> at
> __randomizedtesting.SeedInfo.seed([B72AC4792F31F74B:FD33BC4C549880FE]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at
> org.apache.solr.handler.extraction.TestExtractionDateUtil.assertParsedDate(TestExtractionDateUtil.java:59)
> at
> org.apache.solr.handler.extraction.TestExtractionDateUtil.testParseDate(TestExtractionDateUtil.java:54)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
