Return-Path: X-Original-To: apmail-commons-issues-archive@minotaur.apache.org Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0377D10A3A for ; Sat, 26 Oct 2013 17:18:53 +0000 (UTC) Received: (qmail 49558 invoked by uid 500); 26 Oct 2013 17:18:39 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 49459 invoked by uid 500); 26 Oct 2013 17:18:34 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 49434 invoked by uid 99); 26 Oct 2013 17:18:32 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 26 Oct 2013 17:18:32 +0000 Date: Sat, 26 Oct 2013 17:18:32 +0000 (UTC) From: "Henri Yandell (JIRA)" To: issues@commons.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806140#comment-13806140 ] Henri Yandell commented on LANG-916: ------------------------------------ I just checked out the old r1535653 revision and it installs fine. If the failing tests were time.* related, I strongly suspect it was related to the system date/time of your machine. The 2.x vs 3.x difference is weird; looking at it, I'm guessing that LANG-462 reintroduced the issue though I've not dug into the changelogs yet. It's a little concerning that the LANG-538 and this fix aren't the same. > CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations > ------------------------------------------------------------------------------------------------ > > Key: LANG-916 > URL: https://issues.apache.org/jira/browse/LANG-916 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* > Affects Versions: 3.1 > Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux 3.9.10-100.fc17.i686.PAE). > Reporter: Christian P. MOMON > Labels: patch > Fix For: Review Patch > > Attachments: LANG-916.patch > > > In LANG-538 issue, there is an unit test: > {noformat} > public void testFormat_CalendarIsoMsZulu() { > final String dateTime = "2009-10-16T16:42:16.000Z"; > GregorianCalendar cal = new GregorianCalendar(TimeZone.getTimeZone("GMT-8")); > cal.clear(); > cal.set(2009, 9, 16, 8, 42, 16); > cal.getTime(); > FastDateFormat format = FastDateFormat.getInstance("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)