[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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_PrinterTest>FastDatePrinterTest.testCalendarTimezoneRespected:286
expected:<3:51[AM LIN]T> but was:<3:51[PM CES]T>
FastDateFormat_PrinterTest>FastDatePrinterTest.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("yyyy-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("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/Paris")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Asia/Kolkata")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("yyyy-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)
