[
https://issues.apache.org/jira/browse/LUCENE-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708532#comment-14708532
]
Uwe Schindler commented on LUCENE-6723:
---------------------------------------
Hi Rory, hi Balchandra,
I set up a quick round trip test (it iterates all available timezones in the
JDK, sets them as default, creates a String out of new Date().toString() and
tried to parse that afterwards with ENGLISH, US and ROOT locale.
{code:java}
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Locale;
import java.util.TimeZone;
public final class Test {
private static void testParse(Locale locale, String date) {
try {
new SimpleDateFormat("EEE MMM d hh:mm:ss z yyyy", locale).parse(date);
System.out.println(String.format(Locale.ENGLISH, "OK parsing '%s' in
locale '%s'", date, locale));
} catch (ParseException pe) {
System.out.println(String.format(Locale.ENGLISH, "ERROR parsing '%s' in
locale '%s': %s", date, locale, pe.toString()));
}
}
public static void main(String[] args) {
for (String id : TimeZone.getAvailableIDs()) {
System.out.println("Testing time zone: " + id);
TimeZone.setDefault(TimeZone.getTimeZone(id));
// some date today:
String date1 = new Date(1440358930504L).toString();
testParse(Locale.ENGLISH, date1);
testParse(Locale.US, date1);
testParse(Locale.ROOT, date1);
// half a year back to hit DST difference:
String date2 = new Date(1440358930504L - 86400000L * 180).toString();
testParse(Locale.ENGLISH, date2);
testParse(Locale.US, date2);
testParse(Locale.ROOT, date2);
}
}
}
{code}
With Java 8 this passes, with Java 9 build 78 it fails for several timezones.
The funny thing is: SimpleDateFormat is not even able to parse "UTC" - LOL.
Could you pass this to the issue after reopening? It’s a good test!
> Date field problems using ExtractingRequestHandler and java 9 (b71)
> -------------------------------------------------------------------
>
> Key: LUCENE-6723
> URL: https://issues.apache.org/jira/browse/LUCENE-6723
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Uwe Schindler
> Priority: Critical
> Fix For: 5.3, Trunk, 5.4
>
> Attachments: SOLR-7770.patch
>
>
> Tracking bug to note that the (Tika based) ExtractingRequestHandler will not
> work properly with jdk9 starting with build71.
> This first manifested itself with failures like this from the tests...
> {noformat}
> [junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ExtractingRequestHandlerTest
> -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED
> -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
> [junit4] ERROR 0.58s | ExtractingRequestHandlerTest.testArabicPDF <<<
> [junit4] > Throwable #1: org.apache.solr.common.SolrException: Invalid
> Date String:'Tue Mar 09 13:44:49
> GMT+07:00 2010'
> {noformat}
> Workarround noted by Uwe...
> {quote}
> The test passes on JDK 9 b71 with:
> -Dargs="-Djava.locale.providers=JRE,SPI"
> This reenabled the old Locale data. I will add this to the build parameters
> of policeman Jenkins to stop this from
> failing. To me it looks like the locale data somehow is not able to correctly
> parse weekdays and/or timezones. I
> will check this out tomorrow and report a bug to the OpenJDK people. There is
> something fishy with CLDR locale data.
> There are already some bugs open, so work is not yet finished (e.g. sometimes
> it uses wrong timezone shortcuts,...)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
