[
https://issues.apache.org/struts/browse/WW-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45654#action_45654
]
Lukasz Racon commented on WW-3018:
----------------------------------
"0 and negative numbers fail by type conversion even on English locale." - this
one was fixed in xwork 2.1.3:
http://jira.opensymphony.com/browse/XW-676
> Type conversion for dates and doubles
> -------------------------------------
>
> Key: WW-3018
> URL: https://issues.apache.org/struts/browse/WW-3018
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.1.6
> Reporter: Tamas Ruff
> Priority: Critical
>
> I have recently migrated from struts 2.0.11 to 2.1.6 and the type conversion
> does not work any more as expected for non-English locales.
> Our application is localized (the locale is saved in the session under the
> default WW_TRANS_I18N_LOCALE key).
> I would expect that the submitted date is parsed according to the SHORT
> format of the Locale saved in the session if the i18n interceptor precedes
> the params interceptor in the interceptor stack associated with the action.
> For German locale I would expect to accept the dd.MM.yyyy pattern (but it
> accepts only the MM/dd/yyy pattern).
> I should mention that I do not use the datetimepicker ajax tag from struts2,
> the date is submitted in the format entered by the user.
> The same problem for double numbers: on German locale I would expect to enter
> a decimal number like 1,2 instead of 1.2 but the corresponding double field
> will be set to 12 instead (I suppose the comma is considered thousand
> separator even if the locale is set to German). Moreover the 0 and negative
> numbers fail by type conversion even on English locale.
> For both cases (date and double) it seems that the params interceptor does
> not take into account the locale set in session even if i18n interceptor is
> called before params.
> In the mail archive I found something similar with the datetimepicker but
> that is not my case because in my case the user entered value is submitted to
> the server directly (instead of some "standard" format). Is this a known
> problem and when yes is there some kind of patch/workaound available?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
