[jira] [Commented] (LANG-763) Reintroduce DateUtils.UTC_TIME_ZONE constant

2013-10-26 Thread Benedikt Ritter (JIRA) 

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

Benedikt Ritter commented on LANG-763:
--

Setting this to review patch

 Reintroduce DateUtils.UTC_TIME_ZONE constant
 

 Key: LANG-763
 URL: https://issues.apache.org/jira/browse/LANG-763
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.time.*
Affects Versions: 3.0.1
Reporter: Attila Király
Priority: Minor
 Fix For: Review Patch


 In LANG-691 DateUtils.UTC_TIME_ZONE was removed because TimeZone-s are 
 mutable. However it was a handy constant. So it would be nice if it could be 
 reintroduced in an immutable way. For example:
 - by creating a new static method DateUtils.utcTimeZone() {return 
 TimeZone.getTimeZone(GMT);}
 - or by creating an immutable timezone type (subclassing maybe SimpleTimeZone)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (LANG-763) Reintroduce DateUtils.UTC_TIME_ZONE constant

2013-10-26 Thread Benedikt Ritter (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated LANG-763:
-

Fix Version/s: (was: Patch Needed)
   Review Patch

 Reintroduce DateUtils.UTC_TIME_ZONE constant
 

 Key: LANG-763
 URL: https://issues.apache.org/jira/browse/LANG-763
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.time.*
Affects Versions: 3.0.1
Reporter: Attila Király
Priority: Minor
 Fix For: Review Patch


 In LANG-691 DateUtils.UTC_TIME_ZONE was removed because TimeZone-s are 
 mutable. However it was a handy constant. So it would be nice if it could be 
 reintroduced in an immutable way. For example:
 - by creating a new static method DateUtils.utcTimeZone() {return 
 TimeZone.getTimeZone(GMT);}
 - or by creating an immutable timezone type (subclassing maybe SimpleTimeZone)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (MATH-1043) MathUtils.sum() method to add together a bunch of numbers.

2013-10-26 Thread Gilles (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MATH-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles resolved MATH-1043.
--

Resolution: Not A Problem

Resolving as Won't fix (no feedback from OR in more than 2 months).

 MathUtils.sum() method to add together a bunch of numbers.
 --

 Key: MATH-1043
 URL: https://issues.apache.org/jira/browse/MATH-1043
 Project: Commons Math
  Issue Type: New Feature
 Environment: Any
Reporter: Matt Bishop
Priority: Minor

 I find myself doing sums frequently with a variety of numbers. It would be 
 nice if MathUtils had a method like this:
 int add(int... numbers);



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations

2013-10-26 Thread Christian P. MOMON (JIRA) 

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

Christian P. MOMON commented on LANG-916:
-

No more failed with fresh svn checkout (r1535916 | bayard | 2013-10-26 04:50:25 
+0200). The magic of continuous integration? :-)

After patch:
{noformat}
Failed tests: 
  DateFormatUtilsTest.testTimeISO:165 expected:T1[0]:11:12 but 
was:T1[4]:11:12
  DateFormatUtilsTest.testSMTP:215 expected:Sun, 08 Jun 2003 1[0:11:12 -03]00 
but was:Sun, 08 Jun 2003 1[5:11:12 +02]00
  DateFormatUtilsTest.testDateTimeISO:117 expected:2002-02-23T[09]:11:12 but 
was:2002-02-23T[13]:11:12
  DateFormatUtilsTest.testTimeNoTISO:189 expected:1[0]:11:12 but 
was:1[4]:11:12
  DateFormatUtilsTest.testDateISO:150 expected:2002-02-23[-03]:00 but 
was:2002-02-23[+01]:00
  FastDatePrinterTest.testCalendarTimezoneRespected:286 expected:3:51[AM 
LIN]T but was:3:51[PM CES]T
  FastDatePrinterTest.testLang538:214 dateTime 
expected:2009-10-16T[08]:42:16.000Z but was:2009-10-16T[16]:42:16.000Z
  DurationFormatUtilsTest.testFormatPeriodISO:266 
expected:2002-02-23T[09:11:12-03]:00 but was:2002-02-23T[13:11:12+01]:00
  
FastDateFormat_PrinterTestFastDatePrinterTest.testCalendarTimezoneRespected:286
 expected:3:51[AM LIN]T but was:3:51[PM CES]T
  FastDateFormat_PrinterTestFastDatePrinterTest.testLang538:214 dateTime 
expected:2009-10-16T[08]:42:16.000Z but was:2009-10-16T[16]:42:16.000Z

Tests run: 2382, Failures: 10, Errors: 0, Skipped: 5
{noformat}

 CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in 
 certain situations
 

 Key: LANG-916
 URL: https://issues.apache.org/jira/browse/LANG-916
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.time.*
Affects Versions: 3.1
 Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux 
 3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
  Labels: patch
 Fix For: Review Patch

 Attachments: LANG-916.patch


 In LANG-538 issue, there is an unit test:
 {noformat}
   public void testFormat_CalendarIsoMsZulu() {
 final String dateTime = 2009-10-16T16:42:16.000Z;
 GregorianCalendar cal = new 
 GregorianCalendar(TimeZone.getTimeZone(GMT-8));
 cal.clear();
 cal.set(2009, 9, 16, 8, 42, 16);
 cal.getTime();
 FastDateFormat format = 
 FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z', 
 TimeZone.getTimeZone(GMT));
 assertEquals(dateTime, dateTime, format.format(cal));
   }
 {noformat}
 This test passes successfully in lang-2.6 but failed in lang3-3.1:
 {noformat}
 org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z 
 but was:2009-10-16T[08]:42:16.000Z
 {noformat}
 Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux 
 3.9.10-100.fc17.i686.PAE).
 Moreover, I wrote another unit test showing that the timeZone parameter seems 
 to be ignored :
 {noformat}
 public void test() {
   Calendar cal = 
 Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
   cal.set(2009, 9, 16, 8, 42, 16);
   // 
 System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
   System.out.println(long);
   System.out.println(DateFormatUtils.format(cal.getTimeInMillis(), 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
 TimeZone.getDefault()));
   System.out.println(DateFormatUtils.format(cal.getTimeInMillis(), 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
   TimeZone.getTimeZone(Asia/Kolkata)));
   System.out.println(DateFormatUtils.format(cal.getTimeInMillis(), 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
   TimeZone.getTimeZone(Europe/London)));
   System.out.println(calendar);
   System.out.println(DateFormatUtils.format(cal, 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
 TimeZone.getDefault()));
   System.out.println(DateFormatUtils.format(cal, 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
 TimeZone.getTimeZone(Asia/Kolkata)));
   System.out.println(DateFormatUtils.format(cal, 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
 TimeZone.getTimeZone(Europe/London)));
   System.out.println(calendar fast);
   
 System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z', 
 TimeZone.getTimeZone(Europe/Paris)).format(cal));
   
 System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z', 
 TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
   
 System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z', 
 TimeZone.getTimeZone(Europe/London)).format(cal));
 }
 {noformat}
 Gives the following console

[jira] [Created] (BEANUTILS-447) LazyDynaList.toArray() is not conform to the contract defined by the Collection interface

2013-10-26 Thread Oliver Heger (JIRA) 
Oliver Heger created BEANUTILS-447:
--

 Summary: LazyDynaList.toArray() is not conform to the contract 
defined by the Collection interface
 Key: BEANUTILS-447
 URL: https://issues.apache.org/jira/browse/BEANUTILS-447
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
Affects Versions: 1.8.3
Reporter: Oliver Heger
 Fix For: LATER THAN 1.8.4


The documentation of the toArray(T[]) method says that the passed in array is 
used and returned if its size is sufficient. The implementation of 
{{LazyDynaList}} violates this contract; it always creates a new array.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations

2013-10-26 Thread Henri Yandell (JIRA) 

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

Henri Yandell commented on LANG-916:


I just checked out the old r1535653 revision and it installs fine. If the 
failing tests were time.* related, I strongly suspect it was related to the 
system date/time of your machine. 

The 2.x vs 3.x difference is weird; looking at it, I'm guessing that LANG-462 
reintroduced the issue though I've not dug into the changelogs yet. It's a 
little concerning that the LANG-538 and this fix aren't the same. 

 CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in 
 certain situations
 

 Key: LANG-916
 URL: https://issues.apache.org/jira/browse/LANG-916
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.time.*
Affects Versions: 3.1
 Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux 
 3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
  Labels: patch
 Fix For: Review Patch

 Attachments: LANG-916.patch


 In LANG-538 issue, there is an unit test:
 {noformat}
   public void testFormat_CalendarIsoMsZulu() {
 final String dateTime = 2009-10-16T16:42:16.000Z;
 GregorianCalendar cal = new 
 GregorianCalendar(TimeZone.getTimeZone(GMT-8));
 cal.clear();
 cal.set(2009, 9, 16, 8, 42, 16);
 cal.getTime();
 FastDateFormat format = 
 FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z', 
 TimeZone.getTimeZone(GMT));
 assertEquals(dateTime, dateTime, format.format(cal));
   }
 {noformat}
 This test passes successfully in lang-2.6 but failed in lang3-3.1:
 {noformat}
 org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z 
 but was:2009-10-16T[08]:42:16.000Z
 {noformat}
 Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux 
 3.9.10-100.fc17.i686.PAE).
 Moreover, I wrote another unit test showing that the timeZone parameter seems 
 to be ignored :
 {noformat}
 public void test() {
   Calendar cal = 
 Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
   cal.set(2009, 9, 16, 8, 42, 16);
   // 
 System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
   System.out.println(long);
   System.out.println(DateFormatUtils.format(cal.getTimeInMillis(), 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
 TimeZone.getDefault()));
   System.out.println(DateFormatUtils.format(cal.getTimeInMillis(), 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
   TimeZone.getTimeZone(Asia/Kolkata)));
   System.out.println(DateFormatUtils.format(cal.getTimeInMillis(), 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
   TimeZone.getTimeZone(Europe/London)));
   System.out.println(calendar);
   System.out.println(DateFormatUtils.format(cal, 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
 TimeZone.getDefault()));
   System.out.println(DateFormatUtils.format(cal, 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
 TimeZone.getTimeZone(Asia/Kolkata)));
   System.out.println(DateFormatUtils.format(cal, 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
 TimeZone.getTimeZone(Europe/London)));
   System.out.println(calendar fast);
   
 System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z', 
 TimeZone.getTimeZone(Europe/Paris)).format(cal));
   
 System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z', 
 TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
   
 System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z', 
 TimeZone.getTimeZone(Europe/London)).format(cal));
 }
 {noformat}
 Gives the following console logs:
 {noformat}
 long
 2009-10-16T08:42:16+02:00
 2009-10-16T12:12:16+05:30
 2009-10-16T07:42:16+01:00
 calendar
 2009-10-16T08:42:16+02:00
 2009-10-16T08:42:16+02:00
 2009-10-16T08:42:16+02:00
 calendar fast
 2009-10-16T08:42:16.975Z
 2009-10-16T08:42:16.975Z
 2009-10-16T08:42:16.975Z
 {noformat}
 When DateFormatUtils.format takes a long parameter, the time string is good.
 When DateFormatUtils.format takes a Calendar parameter, the time string is 
 wrong, the timezone parameter is IGNORED.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FUNCTOR-11) Reduce API clutter by removing or reducing scope of FunctorType.equals(FunctorType) methods

2013-10-26 Thread Bruno P. Kinoshita (JIRA) 

[ 
https://issues.apache.org/jira/browse/FUNCTOR-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806144#comment-13806144
 ] 

Bruno P. Kinoshita commented on FUNCTOR-11:
---

http://svn.apache.org/viewvc?view=revisionrevision=r1536009

 Reduce API clutter by removing or reducing scope of 
 FunctorType.equals(FunctorType) methods
 ---

 Key: FUNCTOR-11
 URL: https://issues.apache.org/jira/browse/FUNCTOR-11
 Project: Commons Functor
  Issue Type: Improvement
Reporter: Emmanuel Bourg
Assignee: Bruno P. Kinoshita

 From http://markmail.org/message/ythw55yad5lrvqrj



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (FUNCTOR-11) Reduce API clutter by removing or reducing scope of FunctorType.equals(FunctorType) methods

2013-10-26 Thread Bruno P. Kinoshita (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FUNCTOR-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita resolved FUNCTOR-11.
---

Resolution: Fixed

Remove duplicate equals() methods. All tests run successfully, no extra 
information in PMD, CPD or FindBugs reports.

 Reduce API clutter by removing or reducing scope of 
 FunctorType.equals(FunctorType) methods
 ---

 Key: FUNCTOR-11
 URL: https://issues.apache.org/jira/browse/FUNCTOR-11
 Project: Commons Functor
  Issue Type: Improvement
Reporter: Emmanuel Bourg
Assignee: Bruno P. Kinoshita

 From http://markmail.org/message/ythw55yad5lrvqrj



--
This message was sent by Atlassian JIRA
(v6.1#6144)