[
https://issues.apache.org/jira/browse/LANG-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved LANG-818.
-----------------------
Resolution: Fixed
Fix Version/s: 3.2
Thanks for the code patch and test case.
Test case fails before code patch is applied and succeeds afterwards (as it
should!).
Applied:
URL: http://svn.apache.org/viewvc?rev=1390980&view=rev
Log:
LANG-818 FastDateFormat's "z" pattern does not respect timezone of Calendar
instances passed to format()
Modified:
commons/proper/lang/trunk/src/changes/changes.xml
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/FastDatePrinterTest.java
> FastDateFormat's "z" pattern does not respect timezone of Calendar instances
> passed to format()
> -----------------------------------------------------------------------------------------------
>
> Key: LANG-818
> URL: https://issues.apache.org/jira/browse/LANG-818
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
> Affects Versions: 3.x
> Reporter: Dan Collens
> Fix For: 3.2
>
> Attachments: commons-lang3-LANG-818.patch
>
>
> The work on LANG-462 has introduced a time zone formatting bug in
> FastDateFormat in commons-lang3.
> The problem can be seen by this snippet:
> {code}
> // Always prints timezone name of machine's default timezone, ignoring TZ
> // set on calendar, even though the printed time itself respects calendar's
> TZ.
> Calendar myCal = Calendar.getInstance(TimeZone.getTimeZone("US/Central"));
> System.out.println(FastDateFormat.getInstance("h:mma z").format(myCal));
> {code}
> If you happen to be in US/Central, this will print the right thing, but just
> try it with US/Eastern, US/Pacific, etc. It will print the time in the
> correct timezone, but the timezone name at the end (the "z" pattern) will
> always be the system default timezone. This is a regression against
> commons-lang 2.x.
> Basically, when the "forced time zone" code was removed, the TimeZoneNameRule
> class stopped respecting the Calendar instance's timezone, and instead now
> always uses the mTimeZone of the FastDateFormat instance itself (which is
> only supposed to be used when formatting timezone-less objects such as Date
> or long).
> The removal of the forced time zone stuff is surely the right thing to do (it
> was a mess). I think the fix is to change the TimeZoneNameRule inner class
> to not take a TimeZone instance, but rather to use the TimeZone on the
> Calendar instance passed into appendTo(), just like TimeZoneNumberRule does.
> Presumably then for efficiency, one would use the getTimeZoneDisplay()
> package-static method to quickly retrieve the required timezone's display
> name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
