[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher updated LANG-916:
---
Fix Version/s: (was: Patch Needed)
3.5
> 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
>Assignee: Charles Honton
> Labels: patch, time
> Fix For: 3.5
>
> 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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian P. MOMON updated LANG-916:
Attachment: LANG-916-final-git.patch
Final patch containing fix and 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, 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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-916:
-
Fix Version/s: (was: Review Patch)
Patch Needed
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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian P. MOMON updated LANG-916:
Attachment: LANG-916-C.patch
In order to follow the bug fix LANG-619, I propose an additional test with the
LANG-916-C.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: Review Patch
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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-916:
-
Labels: patch time (was: 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: 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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-916:
---
Fix Version/s: (was: 2.7)
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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-916:
-
Fix Version/s: 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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated LANG-916:
-
Attachment: LANG-916.patch
The attached patch solves the problem by creating a calendar with the correct
timezone from the formatter before actually formatting the object.
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
Fix For: 2.7
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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated LANG-916:
-
Labels: patch (was: )
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
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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-916:
---
Fix Version/s: (was: 2.5)
Commons Time?
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
Fix For: 2.7
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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-916:
---
Fix Version/s: (was: Commons Time?)
2.7
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
Fix For: 2.7
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] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian P. MOMON updated LANG-916:
Affects Version/s: (was: 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 JDK6, RHEL 5.3
Reporter: Christian P. MOMON
Fix For: 2.5
If a Calendar object is constructed in certain ways a call to
Calendar.setTimeZone does not correctly change the Calendars fields. Calling
Calenar.getTime() seems to fix this problem. While this is probably a bug in
the JDK, it would be nice if DateFormatUtils was smart enough to
detect/resolve this problem.
For example, the following unit test fails:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
// more commonly constructed with: cal = new GregorianCalendar(2009, 9,
16, 8, 42, 16)
// for the unit test to work in any time zone, constructing with GMT-8
rather than default locale time zone
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
However, this unit test passes:
{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 message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian P. MOMON updated LANG-916:
Affects Version/s: (was: 2.4)
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.3
Environment: Sun JDK6, RHEL 5.3
Reporter: Christian P. MOMON
Fix For: 2.5
If a Calendar object is constructed in certain ways a call to
Calendar.setTimeZone does not correctly change the Calendars fields. Calling
Calenar.getTime() seems to fix this problem. While this is probably a bug in
the JDK, it would be nice if DateFormatUtils was smart enough to
detect/resolve this problem.
For example, the following unit test fails:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
// more commonly constructed with: cal = new GregorianCalendar(2009, 9,
16, 8, 42, 16)
// for the unit test to work in any time zone, constructing with GMT-8
rather than default locale time zone
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
However, this unit test passes:
{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 message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian P. MOMON updated LANG-916:
Affects Version/s: 3.1
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, 3.3
Environment: Sun JDK6, RHEL 5.3
Reporter: Christian P. MOMON
Fix For: 2.5
If a Calendar object is constructed in certain ways a call to
Calendar.setTimeZone does not correctly change the Calendars fields. Calling
Calenar.getTime() seems to fix this problem. While this is probably a bug in
the JDK, it would be nice if DateFormatUtils was smart enough to
detect/resolve this problem.
For example, the following unit test fails:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
// more commonly constructed with: cal = new GregorianCalendar(2009, 9,
16, 8, 42, 16)
// for the unit test to work in any time zone, constructing with GMT-8
rather than default locale time zone
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
However, this unit test passes:
{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 message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian P. MOMON updated LANG-916:
Description:
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. 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}
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.
was:
If a Calendar object is constructed in certain ways a call to
Calendar.setTimeZone does not correctly change the Calendars fields. Calling
Calenar.getTime() seems to fix this problem. While this is probably a bug in
the JDK, it would be nice if DateFormatUtils was smart enough to detect/resolve
this problem.
For example, the following unit test fails:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
// more commonly constructed with: cal = new GregorianCalendar(2009, 9, 16,
8, 42, 16)
// for the unit test to work in any time zone, constructing with GMT-8
rather than default locale time zone
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
However, this unit test passes:
{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}
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL:
[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian P. MOMON updated LANG-916:
Description:
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. 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.
was:
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. 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}
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,
[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian P. MOMON updated LANG-916:
Description:
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. 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.
was:
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. 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,
[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian P. MOMON updated LANG-916:
Environment:
Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux 3.9.10-100.fc17.i686.PAE).
was:Sun JDK6, RHEL 5.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
Fix For: 2.5
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
