[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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_ParserTest>FastDateParserTest.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_ParserTest>FastDateParserTest.testTimeZoneStrategyPattern:654
français (Belgique):Heure d'Europe de l'Est UTC+3
FastDateFormat_PrinterTest>FastDatePrinterTest.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 attribute, they are initialized on the
first JVM call of the class. So, we would have to set the defau\
lt TimeZone before every tests. But who would want that?
Example:
{noformat}
public void testDateISO(){
[...]
text = DateFormatUtils.ISO_DATE_TIME_ZONE_FORMAT.format(cal);
assertEquals("2002-02-23-03:00", text);
{noformat}
b) Tests depending of the host geographic location (another way)
{noformat}
FastDatePrinterTest.testLang538:215 dateTime
expected:<2009-10-16T[08]:42:16.000Z> but was:<2009-10-16T[16]:42:16.000Z>
FastDateFormat_PrinterTest>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>
{noformat}
These tests are using explicit default timezone from host and make compare
with manual static string. So, the test failed if the tester is not in the same
time zone than the test writer.
c) Test errors already there in r1672030
{noformat}
FastDateFormat_ParserTest>FastDateParserTest.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
{noformat}
End of this test error review. Hope this will help.
> 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("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.3.4#6332)
