Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sun, 5 Jan 2014 09:21:53 +0000 (UTC)
From: "Henri Yandell (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12687174.1388751664969.44209.1388913713136@arcas>
In-Reply-To: <JIRA.12687174.1388751664969@arcas>
References: <JIRA.12687174.1388751664969@arcas>
Subject: [jira] [Commented] (LANG-942) Test failure in FastDateParserTest
 and FastDateFormat_ParserTest when building with JDK8
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LANG-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13862521#comment-13862521 ] 

Henri Yandell commented on LANG-942:
------------------------------------

Seeing if I understand this right.... (paraphrasing Bruno):

The code is failing because the order in Java 8's timezone db changed. The issue is not the test, but that our code is creating a lookup table with four entries:

Timezone short name (this is unique).
Timezone long name (this isn't unique).
Timezone short w/ daylight saving. (per above)
Timezone long w/ daylight saving. (per above)

The two longs aren't unique, making them bad keys. Stepping away from the Map, the issue is with the API of the class.

When parsing text that includes a TimeZone's long name, you can't guarantee there is one answer. Thus we either:

a) Don't offer this feature. Which is easy, remove the two lines from the code and any tests.
b) Choose one of the options.
c) Return all of them [not really feasible, or useful].

Presumably this bug would also appear on older versions of Java, ie: it's not something special to the Java 7 to Java 8 transition.

Looking at SimpleDateFormat, it's matchTimeZone method appears to check the same four items. It behaves differently, returning the first found in the array rather than the last (as ours does). It would appear that the first one found is "America/New York".  Presumably that's the same in Java 7 and 8 (and for all - I bet they add new ones on the end, not the beginning). 

So I think the main issue is in using TimeZone.getAvailableIDs and then TimeZone.getTimeZone(id). Instead we should be using java.text.DateFormatSymbols, and calling the getZoneStrings() method (thus (b) above). We should also not put something in the map if it's already there to match the first in rather than last in style. This does make this Oracle JDK specific behaviour, but I suspect this code is the same in the various JDKs as its typical use of the DateFormatSymbols. Its only our caching and use of a different API that leads to weirdness.

The odd thing is that none of this suggests that we should see an error. It's a rare use to get a Date from a formatter, and then ask the formatter exactly which timezone it used to give you that date. Who cares if it's IET or Michigan eh? Except we're talking about weird TimeZones and I'm betting that we're adding a timezone to the map (with IET) that doesn't actually apply to Eastern Daylight Time during the date we're discussing. Thus the value ends up an hour off. There's a theoretical bug in the JDK here, except I bet they always put the normal timezones above the weird ones, meaning the normal ones get chosen.

Hopefully this all sounds sane and not the ramblings of someone who should be asleep :)

> Test failure in FastDateParserTest and FastDateFormat_ParserTest when building with JDK8
> ----------------------------------------------------------------------------------------
>
>                 Key: LANG-942
>                 URL: https://issues.apache.org/jira/browse/LANG-942
>             Project: Commons Lang
>          Issue Type: Sub-task
>          Components: lang.time.*
>    Affects Versions: 3.2
>         Environment: JDK8
>            Reporter: Benedikt Ritter
>             Fix For: 3.2.1, Patch Needed
>
>
> The following failure is thrown when using JDK 8:
> {code}
> -------------------------------------------------------------------------------
> Test set: org.apache.commons.lang3.time.FastDateFormat_ParserTest
> -------------------------------------------------------------------------------
> Tests run: 29, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.315 sec <<< FAILURE! - in org.apache.commons.lang3.time.FastDateFormat_ParserTest
> testParseZone(org.apache.commons.lang3.time.FastDateFormat_ParserTest)  Time elapsed: 0.005 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<Thu Jul 10 22:33:20 CEST 2003> but was:<Thu Jul 10 23:33:20 CEST 2003>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:144)
> 	at org.apache.commons.lang3.time.FastDateParserTest.testParseZone(FastDateParserTest.java:119)
> 	[...]
> {code}
> It is caused by the following assertion in FastDateParserTest (from which FastDateFormat_ParserTest inherits):
> {code:java}
> assertEquals(cal.getTime(), fdf.parse("2003-07-10T16:33:20.000 Eastern Daylight Time"));
> {code}
> {{FastDateParserTest}} fails with the same error.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)