[jira] [Commented] (LANG-1092) Unit Test failing due to timezone order on JVM/machine

2015-03-13 Thread Benedikt Ritter (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14360864#comment-14360864
 ] 

Benedikt Ritter commented on LANG-1092:
---

After applying the proposed changes, I still get

{code}
Failed tests:
  
FastDateFormat_PrinterTestFastDatePrinterTest.testCalendarTimezoneRespected:282
 expected:2:24PM A[D]T but was:2:24PM A[S]T
  FastDatePrinterTest.testCalendarTimezoneRespected:282 expected:2:24PM A[D]T 
but was:2:24PM A[S]T
{code}

I'm not sure whether this is related...

 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)

[jira] [Commented] (LANG-1092) Unit Test failing due to timezone order on JVM/machine

2015-03-13 Thread Benedikt Ritter (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14360887#comment-14360887
 ] 

Benedikt Ritter commented on LANG-1092:
---

Sorry I misunderstood the suggested changes. We're talking about the same thing 
and I'm now looking into that.

 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)

[jira] [Commented] (LANG-1092) Unit Test failing due to timezone order on JVM/machine

2015-03-13 Thread Benedikt Ritter (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14360900#comment-14360900
 ] 

Benedikt Ritter commented on LANG-1092:
---

This works with:

{code}
java version 1.7.0_71
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
{code}

but fails with:

{code}
java version 1.7.0_75
Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)
{code}

 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)

[jira] [Commented] (LANG-1092) Unit Test failing due to timezone order on JVM/machine

2015-03-13 Thread Benedikt Ritter (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14360971#comment-14360971
 ] 

Benedikt Ritter commented on LANG-1092:
---

The problem is in {{FastDatePrinter$TimeZoneNameRule}}, line 1165-1166. The 
TimeZone returns true for useDaylight, but the offset is 0, so the wrong branch 
is executed resulting in the wrong time zone name being added to the result.

 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)

[jira] [Commented] (LANG-1092) Unit Test failing due to timezone order on JVM/machine

2015-03-12 Thread Benedikt Ritter (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358347#comment-14358347
 ] 

Benedikt Ritter commented on LANG-1092:
---

The time package is killing me... Feel free to commit the suggested 
improvements.

 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)

[jira] [Commented] (LANG-1092) Unit Test failing due to timezone order on JVM/machine

2015-03-12 Thread Henri Yandell (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359792#comment-14359792
 ] 

Henri Yandell commented on LANG-1092:
-

I hear you, I winced when I saw the build was failing in the time package.

My improvement is merely one that makes the test 'work', and fail for everyone.

I think we should remove the time package from 3.4, putting it in its own 
'legacy' jar :)

 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)