[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14522484#comment-14522484 ] Charles Honton commented on LANG-916: - I agree with your reasoning. I'll update the javadoc to make that clear. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=14522422#comment-14522422 ] Christian P. MOMON commented on LANG-916: - I am not agree with you <3 A Calendar parameter is containing an absolute date time information. If I put a calendar parameter and a timezone parameter, it is because I want use this absolute date time with another timezone. The new timezone has priority. This is a common need. So the method is relevant and unambiguous. Is there any error in my reasoning? :D I see that the null timezone case is not described in method comment. If timezone parameter is null then the default timezone is used. Perhaps it would be good to add a comment about it. Because this subject is very different than the LANG-916 subject, can I suggest to create a dedicated issue for it? Regards. :-) > 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
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14522303#comment-14522303 ] Charles Honton commented on LANG-916: - There is a basic problem in the DateFormatUtils.format(Calendar, String pattern, TimeZone, Locale) api. (And furthermore, the FastDateFormat/FastDatePrinter.format(Calendar) apis.) Should the implementation pay attention to the TimeZone set on the Calendar or the TimeZone that is passed in the constructor? I recommend deprecating this method with an explanation what it currently does and what the desired practice should be. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=14520754#comment-14520754 ] Christian P. MOMON commented on LANG-916: - After applying the patch, there is a single unit test which flood ~600 failures. To fix this unit test, I created the LANG-1123 issue and upload a 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: 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] [Commented] (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:comment-tabpanel&focusedCommentId=14520688#comment-14520688 ] Christian P. MOMON commented on LANG-916: - Git is welcome. :-) GitHub is not a free software so I do not use it. On this JIRA, I uploaded an attachment patch file in git format: LANG-916-final-git.patch It contains fix and unit test reproducing the problem. FYI, my ICLA is sent. Let me know if all is good. :-) > 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] [Commented] (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:comment-tabpanel&focusedCommentId=14514864#comment-14514864 ] Benedikt Ritter commented on LANG-916: -- [~cpm] thank you for the effort you're putting into fixing this. Really appreciated! The best would be if we had one single patch file, that contains all we need to fix this and the test reproducing the problem. Can you put that together? Note that we have migrated commons lang to git (see http://commons.apache.org/proper/commons-lang/source-repository.html for the new repository location). If you like, you can also use GitHub for contributing. Just open a PR against github.com/apache/commons-lang. Thank you! > 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] [Commented] (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:comment-tabpanel&focusedCommentId=14501682#comment-14501682 ] Christian P. MOMON commented on LANG-916: - After applying the LANG-916.patch and the LANG-916-B.patch, 9 test failures are remaining (see my review above). These tests are bugged because they are depending of the host geographic location. Do these errors require a new issue/ticket? Or should they be fixed in this one? > 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] [Commented] (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:comment-tabpanel&focusedCommentId=14501675#comment-14501675 ] Christian P. MOMON commented on LANG-916: - After applying the patch from Thomas Neidhart, there is a single test which flood ~600 failures. To fix this test, I had provided the fix LANG-916-B.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: 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] [Commented] (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:comment-tabpanel&focusedCommentId=14501672#comment-14501672 ] Christian P. MOMON commented on LANG-916: - Thomas Neidhart has provided the fix LANG-916.patch. I confirm that this is a good fix. I explain why in the following comment: https://issues.apache.org/jira/browse/LANG-916?focusedCommentId=14484761&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14484761 > 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] [Commented] (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:comment-tabpanel&focusedCommentId=14501500#comment-14501500 ] Benedikt Ritter commented on LANG-916: -- [~cpm]: very nice, I can confirm that LANG-916-C.patch reproduces the bug. Do you have a fix for this? > 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] [Commented] (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:comment-tabpanel&focusedCommentId=14486263#comment-14486263 ] Christian P. MOMON commented on LANG-916: - I am living in Paris (France, Europe) so my timezone is "Europe/Paris" (GMT/UTC +01:00). In Java: {noformat} TimeZone.setDefault(TimeZone.getTimeZone("Europe/Paris")); {noformat} With Unix system command: {noformat} cpm > date jeu. avril 9 00:54:33 CEST 2015 cpm > export TZ="Asia/Kolkata" cpm > date jeu. avril 9 04:24:46 IST 2015 {noformat} Regards. > 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("-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] [Commented] (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:comment-tabpanel&focusedCommentId=14485860#comment-14485860 ] Benedikt Ritter commented on LANG-916: -- [~cpm] thank you for the thorough analysis. What time zone are you in? We should be able to reproduce this by setting the default time zone on our machines to your time zone. > 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("-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] [Commented] (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: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: but was: DateFormatUtilsTest.testTimeISO:176 expected: but was: 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: but was: DateFormatUtilsTest.testTimeISO:176 expected: but was: 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 T
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14484761#comment-14484761 ] Christian P. MOMON commented on LANG-916: - Here are the results of my investigations. A) Thomas Neidhart patch is really good. I confirm that the patch from Thomas Neidhart is the good way. It is easy to verify: FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'", TimeZone.getTimeZone("Asia/Kolkata")).format(cal) 1-> FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'", TimeZone.getTimeZone("Asia/Kolkata")) 2--> .format(cal) 3---> return printer.format(calendar) 4> return format(calendar, new StringBuffer(this.mMaxLengthEstimate)).toString() 5-> return applyRules(calendar, buf); Step 1: store the TimeZone parameter in a FastDateFormat instance and build rules from the pattern to display. Step 5: apply previously build rules to the parameter 'calendar'. So, there is no use of the TimeZone parameter stored in step 1 => **BUG** In his patch, Thomas Neidhart calls the newCalendar(); method which build a new calendar using the TimeZone parameter stored in step 1. Then, this new calendar is used to apply rules. It is exactly what it is done in other methods called "format" too but with a different parameter type (Date, long...). For each, there is a comment "// hard code GregorianCalendar". The method "format" must build a new calendar with the timezone previously stored. B) Test errors come from bad test. Almost all test errors come from a flawed test. In FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected, we can see: final String actualValue = FastDateFormat.getInstance(PATTERN).format(cal); As the TimeZone is not setted, then the TimeZone.getDefault() is set and so it is different than the original timezone. So the displayed result is not the same. Fix: final String actualValue = FastDateFormat.getInstance(PATTERN, this.timeZone).format(cal); It must also be true of other tests. So, definitively, the patch from Thomas Neidhart is the good way. I will try to provide patches for tests. > 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(), >
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14374843#comment-14374843 ] Benedikt Ritter commented on LANG-916: -- Applying the patch blows up a whole lot of tests. [~cpm] can you have a look please? > 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.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13869009#comment-13869009 ] Benedikt Ritter commented on LANG-916: -- [~bayard] where are we standing with this? I'd like to fix all open bugs that are in 'Review Patch' state in the january release (a.k.a. 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 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.5#6160)
[jira] [Commented] (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: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("-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] [Commented] (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: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: but was: DateFormatUtilsTest.testSMTP:215 expected: but was: 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("-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/
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13805594#comment-13805594 ] Henri Yandell commented on LANG-916: Could you list the tests that fail when you build/test straight out of svn? I assume, from the committers involved, that we have people testing successfully in US/Pacific, US/Eastern and CET timezones, > 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] [Commented] (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:comment-tabpanel&focusedCommentId=13805297#comment-13805297 ] Christian P. MOMON commented on LANG-916: - I done the following actions: - svn checkout https://svn.apache.org/repos/asf/commons/proper/lang/trunk commons-lang3 - mvn install => failed because tests failing, then I removed all tests - mvn install, copy the generated jar in my local test project => testFormat_CalendarIsoMsZulu() and test23c2bis() FAILED - I put the patch, mvn install, copy the jar in my local test project => testFormat_CalendarIsoMsZulu() and test23c2bis() finished SUCCESSFULLY I conclude that the patch is good. But I am disappointed that: - before patch, some mvn tests not passed - after patch, some of the passing mvn tests do not passed any longer. Suggestions: - add testFormat_CalendarIsoMsZulu() - add test23c2bis() > 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 parame
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13805296#comment-13805296 ] Christian P. MOMON commented on LANG-916: - Move my System.out.println test in a @Test. {noformat} @Test public void test23c2bis() throws Exception { System.out.println("java_version: " + SystemUtils.JAVA_VERSION); System.out.println(TimeZone.getDefault().getID()); Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("Europe/Paris")); cal.set(2009, 9, 16, 8, 42, 16); // Long. { String value = DateFormatUtils.format(cal.getTimeInMillis(), DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), TimeZone.getDefault()); Assert.assertEquals("long", "2009-10-16T08:42:16+02:00", value); } { String value = DateFormatUtils.format(cal.getTimeInMillis(), DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), TimeZone.getTimeZone("Asia/Kolkata")); Assert.assertEquals("long", "2009-10-16T12:12:16+05:30", value); } { String value = DateFormatUtils.format(cal.getTimeInMillis(), DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), TimeZone.getTimeZone("Europe/London")); Assert.assertEquals("long", "2009-10-16T07:42:16+01:00", value); } // Calendar. { String value = DateFormatUtils.format(cal, DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), TimeZone.getDefault()); Assert.assertEquals("calendar", "2009-10-16T08:42:16+02:00", value); } { String value = DateFormatUtils.format(cal, DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), TimeZone.getTimeZone("Asia/Kolkata")); Assert.assertEquals("calendar", "2009-10-16T12:12:16+05:30", value); } { String value = DateFormatUtils.format(cal, DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(), TimeZone.getTimeZone("Europe/London")); Assert.assertEquals("calendar", "2009-10-16T07:42:16+01:00", value); } // calendar fast. { String value = FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss Z", TimeZone.getTimeZone("Europe/Paris")).format(cal); Assert.assertEquals("calendar", "2009-10-16T08:42:16 +0200", value); } { String value = FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss Z", TimeZone.getTimeZone("Asia/Kolkata")).format(cal); Assert.assertEquals("calendar", "2009-10-16T12:12:16 +0530", value); } { String value = FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss Z", TimeZone.getTimeZone("Europe/London")).format(cal); Assert.assertEquals("calendar", "2009-10-16T07:42:16 +0100", value); } } {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("-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 1
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13805159#comment-13805159 ] Thomas Neidhart commented on LANG-916: -- Ah I forgot to add a 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 > 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] [Commented] (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:comment-tabpanel&focusedCommentId=13805134#comment-13805134 ] Henri Yandell commented on LANG-916: Christian - are you able to test out Thomas' patch? I'm wary to rely on successful builds on my side as they would have passed for 3.1 when that was released. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=13800375#comment-13800375 ] Thomas Neidhart commented on LANG-916: -- The patch was created against trunk, so is for 3.2 > 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] [Commented] (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:comment-tabpanel&focusedCommentId=13800363#comment-13800363 ] Henri Yandell commented on LANG-916: Is the fix version here 2.7 or 3.2? Sounds like it's an issue in 3.1 rather than 2.6. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=13800138#comment-13800138 ] Benedikt Ritter commented on LANG-916: -- Setting this to 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)