You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "David Smiley (JIRA)" <ji...@apache.org> on 2018/06/28 17:48:00 UTC
[jira] [Commented] (SOLR-10243) Fix
TestExtractionDateUtil.testParseDate sporadic failures
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org