[
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-1092:
--------------------------------
Description:
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}
was:
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.:
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
> 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
>
> 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)
