[
https://issues.apache.org/jira/browse/LANG-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-818:
------------------------------
Attachment: commons-lang3-LANG-818.patch
I've attached a patch that I believe addresses this issue, plus a unit test to
prove correctness.
The only minor issue is that the estimated length provided by
TimeZoneNameRule.estimateLength() is now based on the wrong timezone. I can't
see a way to avoid this.
Perhaps it would be better to artificially increase the returned estimated
length value on the basis that over-provisioning a StringBuffer is better than
under-provisioning?
> 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
> 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
