[ 
https://issues.apache.org/struts/browse/WW-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Musachy Barroso resolved WW-3018.
---------------------------------

    Resolution: Duplicate

This is a know problem in 2.1.6 (in xwork 2.1.2 actually), see: 
http://jira.opensymphony.com/browse/XW-670

thanks for reporting.

> 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.

Reply via email to