[ https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benedikt Ritter updated LANG-1092: ---------------------------------- Fix Version/s: 3.4 Review Patch > Unit Test failing due to timezone order on JVM/machine > ------------------------------------------------------ > > Key: LANG-1092 > URL: https://issues.apache.org/jira/browse/LANG-1092 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* > Affects Versions: 3.3.2 > Reporter: Henri Yandell > Fix For: Review Patch, 3.4 > > > At work we're getting build issues with Lang 3.3.2 (and any since 3.2 when > the test code was introduced in LANG-818). The test > org.apache.commons.lang3.time.FastDatePrinterTest.testCalendarTimezoneRespected > picks a timezone and runs a test on it. One assumes that timezones usually > work, but some are not - so it depends on the order of timezones returned by > TimeZone.getAvailableIDs(). > This would seem to imply a daylight savings time bug in FastDateFormat. This > may be the same issue as LANG-916. > If you adjust the for loop such that the test is within the loop and happens > on every timezone, you will hit timezones that fail. e.g.: > {code} > Index: FastDatePrinterTest.java > =================================================================== > --- FastDatePrinterTest.java (revision 1665715) > +++ FastDatePrinterTest.java (working copy) > @@ -269,8 +269,6 @@ > for (final String zone : availableZones) { > if (!zone.equals(currentZone.getID())) { > anotherZone = TimeZone.getTimeZone(zone); > - } > - } > > assertNotNull("Cannot find another timezone", anotherZone); > > @@ -282,6 +280,8 @@ > final String expectedValue = sdf.format(cal.getTime()); > final String actualValue = > FastDateFormat.getInstance(pattern).format(cal); > assertEquals(expectedValue, actualValue); > + } > + } > } > > @Test > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)