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

[Charles Honton (JIRA)]

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

Charles Honton commented on LANG-916:
-

There is a basic problem in the DateFormatUtils.format(Calendar, String 
pattern, TimeZone, Locale) api.  (And furthermore, the 
FastDateFormat/FastDatePrinter.format(Calendar) apis.)  Should the 
implementation pay attention to the TimeZone set on the Calendar or the 
TimeZone that is passed in the constructor?   I recommend deprecating this 
method with an explanation what it currently does and what the desired practice 
should be.


 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, time
 Fix For: Patch Needed

 Attachments: LANG-916-B.patch, LANG-916-C.patch, 
 LANG-916-final-git.patch, 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.3.4#6332)

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

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

I am not agree with you 3 A Calendar parameter is containing an absolute date 
time information. If I put a calendar parameter and a timezone parameter, it is 
because I want use this absolute date time with another timezone. The new 
timezone has priority. This is a common need. So the method is relevant and 
unambiguous.

Is there any error in my reasoning? :D

I see that the null timezone case is not described in method comment. If 
timezone parameter is null then the default timezone is used. Perhaps it would 
be good to add a comment about it.

Because this subject is very different than the LANG-916 subject, can I suggest 
to create a dedicated issue for it?

Regards. :-)

 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, time
 Fix For: Patch Needed

 Attachments: LANG-916-B.patch, LANG-916-C.patch, 
 LANG-916-final-git.patch, 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.3.4#6332)

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

[Charles Honton (JIRA)]

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

Charles Honton commented on LANG-916:
-

I agree with your reasoning.  I'll update the javadoc to make that clear.

 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, time
 Fix For: Patch Needed

 Attachments: LANG-916-B.patch, LANG-916-C.patch, 
 LANG-916-final-git.patch, 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.3.4#6332)

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

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

Git is welcome. :-) GitHub is not a free software so I do not use it. 

On this JIRA, I uploaded an attachment patch file in git format: 
LANG-916-final-git.patch
It contains fix and unit test reproducing the problem.

FYI, my ICLA is sent.
Let me know if all is good. :-)



 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, time
 Fix For: Patch Needed

 Attachments: LANG-916-B.patch, LANG-916-C.patch, 
 LANG-916-final-git.patch, 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.3.4#6332)

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

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

After applying the patch, there is a single unit test which flood ~600 
failures. To fix this unit test, I created the LANG-1123 issue and upload a 
patch file.

 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, time
 Fix For: Patch Needed

 Attachments: LANG-916-B.patch, LANG-916-C.patch, 
 LANG-916-final-git.patch, 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.3.4#6332)

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

[Benedikt Ritter (JIRA)]

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

Benedikt Ritter commented on LANG-916:
--

[~cpm] thank you for the effort you're putting into fixing this. Really 
appreciated! The best would be if we had one single patch file, that contains 
all we need to fix this and the test reproducing the problem. Can you put that 
together? Note that we have migrated commons lang to git (see 
http://commons.apache.org/proper/commons-lang/source-repository.html for the 
new repository location). If you like, you can also use GitHub for 
contributing. Just open a PR against github.com/apache/commons-lang.

Thank you!

 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, time
 Fix For: Patch Needed

 Attachments: LANG-916-B.patch, LANG-916-C.patch, 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.3.4#6332)

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

[Benedikt Ritter (JIRA)]

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

Benedikt Ritter commented on LANG-916:
--

[~cpm]: very nice, I can confirm that LANG-916-C.patch reproduces the bug. Do 
you have a fix for this?

 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, time
 Fix For: Patch Needed

 Attachments: LANG-916-B.patch, LANG-916-C.patch, 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.3.4#6332)

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

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

Thomas Neidhart has provided the fix LANG-916.patch. I confirm that this is a 
good fix.

I explain why in the following comment: 
https://issues.apache.org/jira/browse/LANG-916?focusedCommentId=14484761page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14484761


 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, time
 Fix For: Patch Needed

 Attachments: LANG-916-B.patch, LANG-916-C.patch, 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.3.4#6332)

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

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

After applying the patch from Thomas Neidhart, there is a single test which 
flood ~600 failures. To fix this test, I had provided the fix LANG-916-B.patch


 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, time
 Fix For: Patch Needed

 Attachments: LANG-916-B.patch, LANG-916-C.patch, 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.3.4#6332)

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

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

After applying the LANG-916.patch and the LANG-916-B.patch, 9 test failures are 
remaining (see my review above). These tests are bugged because they are 
depending of the host geographic location. 

Do these errors require a new issue/ticket? Or should they be fixed in this one?

 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, time
 Fix For: Patch Needed

 Attachments: LANG-916-B.patch, LANG-916-C.patch, 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.3.4#6332)

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

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

This is a test error review after applying the patch LANG-916.patch file.

About the revison I am using:
{noformat}
cpm  svn  log -l 1

r1672030 | djones | 2015-04-08 10:38:02 +0200 (mer. 08 avril 2015) | 1 ligne

cpm  svn info
URL: https://svn.apache.org/repos/asf/commons/proper/lang/trunk
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1672106
Node Kind: directory
Schedule: normal
Last Changed Author: djones
Last Changed Rev: 1672030
Last Changed Date: 2015-04-08 10:38:02 +0200 (Wed, 08 Apr 2015)
{noformat}


List test errors existing in trunk before any change:
{noformat}
cpm  mvn test
[...]
Failed tests:
  FastDateFormat_ParserTestFastDateParserTest.testTimeZoneStrategyPattern:654 
français (Belgique):Heure d'Europe de l'Est UTC+3
  FastDateParserTest.testTimeZoneStrategyPattern:654 français (Belgique):Heure 
d'Europe de l'Est UTC+3
[...]
Tests run: 3544, Failures: 2, Errors: 0, Skipped: 5
{noformat}


Apply the Thomas Neidhart patch:
{noformat}
cpm  svn patch ../LANG-916/LANG-916.patch
U src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
 application bloc @@ -458,7 +458,9 @@ décallage 19
{noformat}

List test errors after applying the patch LANG-916.patch file:
{noformat}
cpm  mvn test
Failed tests:
[...]
  FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61 
expected:[2:19PM EDT] but was:[6:19PM UTC]
  FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61 
expected:[2:19PM AST] but was:[6:19PM UTC]
  FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61 
expected:[12:19PM MDT] but was:[6:19PM UTC]
  FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61 
expected:[1:19PM ACT] but was:[6:19PM UTC]
[...]
Tests run: 3544, Failures: 617, Errors: 0, Skipped: 5
{noformat}

Apply the LANG-916-B.patch file to fix a missing timezone set wich make one 
test flooding errors:
{noformat}
cpm  svn patch ../LANG-916/LANG-916-B.patch
U 
src/test/java/org/apache/commons/lang3/time/FastDatePrinterTimeZonesTest.java
{noformat}

List test errors remaining after applying the patch LANG-916-B.patch file:
{noformat}
cpm  mvn test
Failed tests:
Results :

Failed tests:
  DateFormatUtilsTest.testDateISO:161 expected:2002-02-23[-03]:00 but 
was:2002-02-23[+01]:00
  DateFormatUtilsTest.testDateTimeISO:120 expected:2002-02-23T[09]:11:12 but 
was:2002-02-23T[13]:11:12
  DateFormatUtilsTest.testSMTP:226 expected:Sun, 08 Jun 2003 1[0:11:12 -03]00 
but was:Sun, 08 Jun 2003 1[5:11:12 +02]00
  DateFormatUtilsTest.testTimeISO:176 expected:T1[0]:11:12 but 
was:T1[4]:11:12
  DateFormatUtilsTest.testTimeNoTISO:200 expected:1[0]:11:12 but 
was:1[4]:11:12
  DurationFormatUtilsTest.testFormatPeriodISO:270 
expected:2002-02-23T[09:11:12-03]:00 but was:2002-02-23T[13:11:12+01]:00
  FastDateFormat_ParserTestFastDateParserTest.testTimeZoneStrategyPattern:654 
français (Belgique):Heure d'Europe de l'Est UTC+3
  FastDateFormat_PrinterTestFastDatePrinterTest.testLang538:215 dateTime 
expected:2009-10-16T[08]:42:16.000Z but was:2009-10-16T[16]:42:16.000Z
  FastDateParserTest.testTimeZoneStrategyPattern:654 français (Belgique):Heure 
d'Europe de l'Est UTC+3
  FastDatePrinterTest.testLang538:215 dateTime 
expected:2009-10-16T[08]:42:16.000Z but was:2009-10-16T[16]:42:16.000Z
  FastDatePrinterTest.testTimeZoneAsZ:270 expected:+0[0]00 but was:+0[2]00

Tests run: 3544, Failures: 11, Errors: 0, Skipped: 5
{noformat}

So, only 11 failures are remaining. These test errors can be sort like this:

a) Tests depending of the host geographic location
{noformat}
  DateFormatUtilsTest.testDateISO:161 expected:2002-02-23[-03]:00 but 
was:2002-02-23[+01]:00
  DateFormatUtilsTest.testDateTimeISO:120 expected:2002-02-23T[09]:11:12 but 
was:2002-02-23T[13]:11:12
  DateFormatUtilsTest.testSMTP:226 expected:Sun, 08 Jun 2003 1[0:11:12 -03]00 
but was:Sun, 08 Jun 2003 1[5:11:12 +02]00
  DateFormatUtilsTest.testTimeISO:176 expected:T1[0]:11:12 but 
was:T1[4]:11:12
  DateFormatUtilsTest.testTimeNoTISO:200 expected:1[0]:11:12 but 
was:1[4]:11:12
  DurationFormatUtilsTest.testFormatPeriodISO:270 
expected:2002-02-23T[09:11:12-03]:00 but was:2002-02-23T[13:11:12+01]:00
{noformat}

 These tests are using some DateFormatUtils static constants which are defined 
with the default TimeZone depending of the host and his geographical location. 
In the assert, the changing result is compare with a manu\
al constant string value. So, the test failed if the tester is not in the same 
time zone than the test writer.

 The worst part is that you can not change the TimeZone associated to these 
DateFormatUtils constants. As static 

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

[Benedikt Ritter (JIRA)]

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

Benedikt Ritter commented on LANG-916:
--

[~cpm] thank you for the thorough analysis. What time zone are you in? We 
should be able to reproduce this by setting the default time zone on our 
machines to your time zone.

 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, time
 Fix For: Review Patch

 Attachments: LANG-916-B.patch, 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.3.4#6332)

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

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

I am living in Paris (France, Europe) so my timezone is Europe/Paris (GMT/UTC 
+01:00).

In Java:
{noformat}
TimeZone.setDefault(TimeZone.getTimeZone(Europe/Paris));
{noformat}

With Unix system command:
{noformat}
cpm  date
jeu. avril  9 00:54:33 CEST 2015
cpm  export TZ=Asia/Kolkata
cpm  date
jeu. avril  9 04:24:46 IST 2015
{noformat}

Regards.

 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, time
 Fix For: Review Patch

 Attachments: LANG-916-B.patch, 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.3.4#6332)

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

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

Here are the results of my investigations.

A) Thomas Neidhart patch is really good.
I confirm that the patch from Thomas Neidhart is the good way. 
It is easy to verify:

FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z', 
TimeZone.getTimeZone(Asia/Kolkata)).format(cal)

1- FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z', 
TimeZone.getTimeZone(Asia/Kolkata))
2-- .format(cal) 
3--- return  printer.format(calendar)
4 return format(calendar, new 
StringBuffer(this.mMaxLengthEstimate)).toString()
5- return applyRules(calendar, buf);

Step 1: store the TimeZone parameter in a FastDateFormat instance and build 
rules from the pattern to display.
Step 5: apply previously build rules to the parameter 'calendar'. So, there is 
no use of the TimeZone parameter stored in step 1 = **BUG**

In his patch, Thomas Neidhart calls the newCalendar(); method which build a new 
calendar using the TimeZone parameter stored in step 1. Then, this new calendar 
is used to apply rules.

It is exactly what it is done in other methods called format too but with a 
different parameter type (Date, long...). For each, there is a comment // hard 
code GregorianCalendar.

The method format must build a new calendar with the timezone previously 
stored.


B) Test errors come from bad test.
Almost all test errors come from a flawed test. In 
FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected, we can see:

final String actualValue = FastDateFormat.getInstance(PATTERN).format(cal);

As the TimeZone is not setted, then the TimeZone.getDefault() is set and so it 
is different than the original timezone. So the displayed result is not the 
same.

Fix: final String actualValue = FastDateFormat.getInstance(PATTERN, 
this.timeZone).format(cal);

It must also be true of other tests.


So, definitively, the patch from Thomas Neidhart is the good way.

I will try to provide patches for tests.

 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, time
 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, 
 

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

[Benedikt Ritter (JIRA)]

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

Benedikt Ritter commented on LANG-916:
--

Applying the patch blows up a whole lot of tests. [~cpm] can you have a look 
please?

 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, time
 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.3.4#6332)

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

[Benedikt Ritter (JIRA)]

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

Benedikt Ritter commented on LANG-916:
--

[~bayard] where are we standing with this? I'd like to fix all open bugs that 
are in 'Review Patch' state in the january release (a.k.a. 3.3)

 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.5#6160)

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

[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] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations

[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] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations

[Henri Yandell (JIRA)]

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

Henri Yandell commented on LANG-916:


Christian - are you able to test out Thomas' patch? I'm wary to rely on 
successful builds on my side as they would have passed for 3.1 when that was 
released.

 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] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations

[Thomas Neidhart (JIRA)]

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

Thomas Neidhart commented on LANG-916:
--

Ah I forgot to add a unit test ...

 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] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

Move my System.out.println test in a @Test.

{noformat}
@Test
public void test23c2bis() throws Exception {

System.out.println(java_version:  + SystemUtils.JAVA_VERSION);

System.out.println(TimeZone.getDefault().getID());
Calendar cal = 
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);

// Long.
{
String value = 
DateFormatUtils.format(cal.getTimeInMillis(), 
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
TimeZone.getDefault());
Assert.assertEquals(long, 
2009-10-16T08:42:16+02:00, value);
}
{
String value = 
DateFormatUtils.format(cal.getTimeInMillis(), 
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata));
Assert.assertEquals(long, 
2009-10-16T12:12:16+05:30, value);
}
{
String value = 
DateFormatUtils.format(cal.getTimeInMillis(), 
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London));
Assert.assertEquals(long, 
2009-10-16T07:42:16+01:00, value);
}

// Calendar.
{
String value = DateFormatUtils.format(cal, 
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
TimeZone.getDefault());
Assert.assertEquals(calendar, 
2009-10-16T08:42:16+02:00, value);
}
{
String value = DateFormatUtils.format(cal, 
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
TimeZone.getTimeZone(Asia/Kolkata));
Assert.assertEquals(calendar, 
2009-10-16T12:12:16+05:30, value);
}
{
String value = DateFormatUtils.format(cal, 
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), 
TimeZone.getTimeZone(Europe/London));
Assert.assertEquals(calendar, 
2009-10-16T07:42:16+01:00, value);
}

// calendar fast.
{
String value = 
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss Z, 
TimeZone.getTimeZone(Europe/Paris)).format(cal);
Assert.assertEquals(calendar, 2009-10-16T08:42:16 
+0200, value);
}
{
String value = 
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss Z, 
TimeZone.getTimeZone(Asia/Kolkata)).format(cal);
Assert.assertEquals(calendar, 2009-10-16T12:12:16 
+0530, value);
}
{
String value = 
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss Z, 
TimeZone.getTimeZone(Europe/London)).format(cal);
Assert.assertEquals(calendar, 2009-10-16T07:42:16 
+0100, value);
}
}
{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 

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

[Christian P. MOMON (JIRA)]

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

Christian P. MOMON commented on LANG-916:
-

I done the following actions:
- svn checkout https://svn.apache.org/repos/asf/commons/proper/lang/trunk 
commons-lang3
- mvn install = failed because tests failing, then I removed all tests
- mvn install, copy the generated jar in my local test project = 
testFormat_CalendarIsoMsZulu() and test23c2bis()  FAILED
- I put the patch, mvn install, copy the jar in my local test project = 
testFormat_CalendarIsoMsZulu() and test23c2bis() finished SUCCESSFULLY

I conclude that the patch is good. But I am disappointed that:
- before patch, some mvn tests not passed
- after patch, some of the passing mvn tests do not passed any longer.

Suggestions:
- add testFormat_CalendarIsoMsZulu()
- add test23c2bis() 

 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] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations

[Henri Yandell (JIRA)]

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

Henri Yandell commented on LANG-916:


Could you list the tests that fail when you build/test straight out of svn? I 
assume, from the committers involved, that we have people testing successfully 
in US/Pacific, US/Eastern and CET timezones, 

 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] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations

[Benedikt Ritter (JIRA)]

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

Benedikt Ritter commented on LANG-916:
--

Setting this to Review Patch. 

 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: 2.7, 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] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations

[Henri Yandell (JIRA)]

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

Henri Yandell commented on LANG-916:


Is the fix version here 2.7 or 3.2? Sounds like it's an issue in 3.1 rather 
than 2.6.

 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: 2.7, 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] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations

[Thomas Neidhart (JIRA)]

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

Thomas Neidhart commented on LANG-916:
--

The patch was created against trunk, so is for 3.2

 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: 2.7, 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)