commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian P. MOMON (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
Date Wed, 08 Apr 2015 18:47:12 GMT

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

Christian P. MOMON edited comment on LANG-916 at 4/8/15 6:46 PM:
-----------------------------------------------------------------

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}

Failure count is huge but almost 600 failures come from a single test.
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 manual 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 default 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.


was (Author: cpm):
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}

Failure count is huge but almost 600 failures come from a single test.
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 manual 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)

Mime
View raw message