commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LANG-1092) Unit Test failing due to timezone order on JVM/machine
Date Tue, 10 Mar 2015 23:30:38 GMT

     [ 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)

Mime
View raw message