You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Henri Yandell (JIRA)" <ji...@apache.org> on 2015/03/11 00:30:38 UTC
[jira] [Updated] (LANG-1092) Unit Test failing due to timezone
order on JVM/machine
[ 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)